Re: Continual creation is a memory leak

2011-12-14 Thread Chris Murphy (www.strandz.org)
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 ret

Re: Continual creation is a memory leak

2011-12-13 Thread Malcolm Edgar
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 o

Re: Continual creation is a memory leak

2011-12-12 Thread Chris Murphy
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 rea

RE: Continual creation is a memory leak

2011-12-12 Thread Durchholz, Joachim
> 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 be

Re: Continual creation is a memory leak

2011-12-12 Thread Chris Murphy (www.strandz.org)
Quite interestingly two was not enough. I got the error again after leaving the server going for one and a half hours. My theory as to why two connections was not enough is that I was relying on garbage collection to have flushed away everything (including the connection) associated with the old 'o

Re: Continual creation is a memory leak

2011-12-11 Thread Robert Zeigler
You're right about the max # of concurrent users, but the max # of required connections is usually < the max # of concurrent users. Cayenne only needs a connection to query the db or to commit to the db. Outside of those operations, connections are returned to the pool, so you can usually get by

Re: Continual creation is a memory leak

2011-12-11 Thread Chris Murphy (www.strandz.org)
I just had a look at the Modeler and at the DomainNode's JDBC Configuration (in the Main tab). I saw that 'Max Connections' was set to '1'. So perhaps I wasn't giving Cayenne much to play with in terms of connection pooling! I have now set it to '2'. (I imagine the default was a bit higher than the

Re: Continual creation is a memory leak

2011-12-11 Thread Robert Zeigler
Hm. Cayenne is usually pretty good about managing the connection pooling for you. How many concurrent connections is your mysql db configured to allow? Robert On Dec 11, 2011, at 12/119:58 PM , Chris Murphy (www.strandz.org) wrote: > Thanks Robert, > > That was the answer. The memory leak disa

Re: Continual creation is a memory leak

2011-12-11 Thread Chris Murphy (www.strandz.org)
Thanks Robert, That was the answer. The memory leak disappeared. I now create a DataContext with 'method scope' that gets gc-ed when the method has finished. That brought up what must be another problem with my code which I'm investigating now: Caused by: org.apache.cayenne.CayenneRuntimeExceptio

Re: Continual creation is a memory leak

2011-12-10 Thread Robert Zeigler
Note that DataContext creation is cheap. What I typically do in situations like this is to periodically create a new data context that you can throw away. When it's gone, the associated objects will be gc'ed. Eg: you could periodically dump the "reading" data context and create a fresh one after

Continual creation is a memory leak

2011-12-10 Thread Chris Murphy (www.strandz.org)
I have a server application that continually reads data from sensors. At set intervals the data is summarized. This summary data is used to create Cayenne data objects of type Reading. A short transaction commits these Reading objects to the database, after which it is not important that they are h