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 DataSourceFactory. regards Malcolm Edgar On Tue, Dec 13, 2011 at 5:22 AM, Chris Murphy <mur...@gmail.com> 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 < > joachim.durchh...@hennig-fahrzeugteile.de> 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 >>
