Problems with thread exceeding cache size and garbage collection

[William Ross]

Say that I am taking a number of threads off of a queue. My cache is an arbitrary size of 2000. Now the first thread is 1300 and the 2nd is 1200. Since the 2nd one is too big to go into the cache I get an exception. How, can I recover from this exception? Should I be doing garbage collection manually here? Sorry, if my question is hard to understand I haven't done too much work with threading before.

[Ernest Friedman-Hill]

Hi,

Welcome to JavaRanch!

Cache of what? 2000 what? 1200 what? 1300 what?

Can you just catch the exception in your run() implementation, and deal with it?

[William Ross]

I'm not really sure; I was just saying like arbitrary units. Say for Example 2000MB, 1300MB, and 1200MB. One of my office mates asked me this question to post it... I'll see if I can get more info about the problem. Thanks.

[Henry Wong]

How, can I recover from this exception? Should I be doing garbage collection manually here?

The system will GC as it needs memory -- so if you get an out of memory error, all the garbage have been pretty much clean up.

Now... if the cache is just that -- a cache and not a critical datastore. You can rewrite the cache using weak references. This way, as the system needs memory, it can GC the cache as well.

Henry

[William Ross]

It is not a critical datastore but I don't have control over the cache because it is being run in WebLogic. WebLogic is in control of the queueing of threads. The exception being thrown is a java.lang.OutOfMemoryError. Also, the reference is pulling in a buffered image. The garbage collector can't take the entire chunk back since it is one reference.

[Jim Yingst]

[Henry]: so if you get an out of memory error, all the garbage have been pretty much clean up.

That's true at the point the exception was thrown. However at the point you catch the exception, you've already at least abandoned the attempted action which requred extra memory, and you may well have exited several other blocks and/or methods, making additional variables go out of scope, and allowing additional memory available to GC. Depending on what you're doing and how your code is organized, it may be perfectly reasonable to catch the exception and attemtp to proceed anyway. The critical question being - how important was the method call that threw the exception? Is it possible to proceed if that failed? Often the answer is no, but sometimes it's yes. Can't say much more in general - it all depends on the details of what one is doing here, I think.

[Mr. C Lamont Gilbert]

You meant to say SoftReference Mr. Wong.

[Henry Wong]

Originally posted by Mr. C Lamont Gilbert:
You meant to say SoftReference Mr. Wong.

This is actually a good point. Yes, I do mean the SoftReference class, but how do I reference (no pun intended) the package with something that can be googled? "weak references" seems to be a more commonly used term.

I don't like "references package". Maybe "java.lang.ref package" is better. Opinions appreciated...

Henry

[Mr. C Lamont Gilbert]

like this?

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ref/package-frame.html