Hi Malcolm, I need to do everything to ensure that this server will stay up. So yes if you can give me the code you used I will add it in for logging purposes, to hopefully see what each requested connection is being used for, and thus if any are not being reused, indicating they have not been returned to the pool.
Meanwhile I can look at the log file to see if there are any stack traces in it. My thinking being that usually a thread-death will be marked by some kind of stack trace. Even simply knowing how many connections are in use at any one time, over time, will give me some peace of mind. I expect to see two being used. I have evidence that three have been needed on occasion. If I see four being used after a longer period of the server being up, then I can predict that five and then a "Too many connections" crash will be on the horizon - as I have set 'max connections' to five. Thank you. ~ Chris Murphy On 13 December 2011 20:38, Malcolm Edgar <malcolm.ed...@gmail.com> wrote: > 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 > >> >
