cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Continual creation is a memory leak
Date Tue, 13 Dec 2011 09:38:54 GMT
Hi Chris,

I once had an issue with JBoss 4.0.3 in a production environment where
connections were not being returned to the pool and eventually the
application would crash through connection pool exhaustion.

It took a long time to figure out what was happening, it appeared that
we has some kind of thread-dealth like behaviour with some connections
never being closed and returned to the pool. The fix for this was to
create a connection wrapper, so we could track whether connections
were being returned to the pool with a request filter.  If you are
interested I can provide the code, which is plugged in with a Cayenne

regards Malcolm Edgar

On Tue, Dec 13, 2011 at 5:22 AM, Chris Murphy <> wrote:
> I'm using JProfiler to look for memory leaks. I've used it to see that
> they've been plugged since I implemented Robert's suggestion of having a
> separate temporary DataContext that gets garbage collected, collecting the
> Reading data objects with it.
> I now think that garbage collection being the reason for three connections
> to be required is quite silly! If a connection is ready for garbage
> collection then it won't be visible to the Cayenne code. The Cayenne code
> is baulking because two connections are currently in use and a third is
> required to execute a query (that's my understanding of the error message).
> To really see the cause of the problem it would be good if the "Too many
> connections" stack trace told us what the other two connections are being
> used for. Alternatively the instrumention at the DEBUG logging level might
> show connections being picked up and released, and I would be able to work
> out why the other two are being held from there.
>  ~ Chris Murphy
> On 13 December 2011 00:50, Durchholz, Joachim <
>> wrote:
>> > Perhaps the garbage collector thinks that its okay to leave around such
>> a small amount of garbage for more than a minute.
>> >
>> > Am I right?? It sounds weird that a garbage collector can cause a
>> program to crash!
>> Probably not. Garbage collectors will kick in after a certain threshold
>> has been reached, and that threshold is usually set at the end of the last
>> cycle.
>> In other words, unless you have a real memory leak, the collector should
>> keep the memory footprint stable. It's part of its job description.
>> (The actual mechanism is far more complicated, but that's the bottom line).
>> If you are using Sun's Java 6, you can monitor memory usage via JVisualVM,
>> which comes as part of the JDK.
>> JVisualVM also works well for Sun's Java 5 runtime. You'll have slightly
>> reduced functionality and you need to supply an extra -D parameter to the
>> Java 5 RE, but it does give you the pretty real-time graphs. That tool
>> helped me a ton, a year or two ago, with little hassle for set-up, despite
>> being tied to Java 5 at that time. (JVisualVM will even give you statistics
>> about which data types take up most memory, show you all objects of a type,
>> and will even do a breadth-first search for a stack frame that's keeping
>> any given object alive. I'm not 100% sure how much of this is available for
>> Java 5, but if Java 5 fails you can still try Java 6.)
>> HTH
>> Jo

View raw message