What happens when a collection in Java grows out of capacity?

Question

I have a service that handles all the calls made in it in memory, because we do not want to lose data, and at the same time we need this service, which ever fails due to any external dependency (e.g. DB ) Then these phased calls are usually collected and processed in the background.

If for any reason, if there are too many calls, and we run out of memory, we need to be alarmed.

So, the question is simply posed: what is the exception that I need to catch or track in order to notify me when the failure due to insufficient resources has not completed? Will this be the result of OOM in the virtual machine itself, or is there a limit to the collection level?

If there is no limit to the collection level, how would you recommend I control the use of the service? We currently use heap and memory usage metrics. It's enough? In addition, the JVMs are configured to kill on an OOM error (this is because the VM manager then restarts any process that it manages on the kill).

Answer 1

The exception is an OutOfMemoryException . This exception can be thrown to any part of your application as soon as your collection uses the entire available heap area.

However, if you know that this could potentially be thrown for a particular collection, the best way could be to prevent this, i.e. limiting this collection or using caching so that unused objects are unloaded and reloaded on demand. For a lightweight cache implementation, I would recommend Guava CacheBuilder .

UPDATE

Since everyone offers FS-based storage, here is my easy suggestion:

• CacheBuilder for loading serialized data from a NoSQL database
• Kryo serializer to convert your objects to byte[]
• MapDB for storage (or any other NoSQL built-in solution you prefer).

Answer 2

Here is what I found in the Collection.add spec:

If the collection refuses to add a specific element for any reason other than the one that already contains the element, it should throw an exception (and not return false). This preserves the invariant that the collection always contains the specified element after the return of this call.

It does not indicate which exception, so different collections may cause different exceptions.

Answer 3

I think letting an unsuccessful application fail is not an ideal design choice. You should have a collection size threshold and decide what to do in this case: clean it somewhere (disk?), Send a notification (JMX / email), throw an error (or let OOME spread).

However, I will give you a design recommendation. From your brief and slightly cryptic description of the service, it sounds to me as if you need a work queue to sit somewhere outside your service, for example, a JMS server or even a database. That way, your background process will be able to receive the request from the queue (db) and process it, even if your service died for any reason.