On 7/21/05, Danilo Tommasina <[EMAIL PROTECTED]> wrote: > Hi there > > are there any news about this issue? do you need more information? > > Robert? did you find out if you have pool/connection eviction threads running? > > you can disable automaitc eviction by setting in OJB.properties: > timeBetweenEvictionRunsMillis=-1 > > and by setting the attribute timeBetweenEvictionRunsMillis="-1" in your > connection-pool settings in the repository.xml > > Please note that somebody else reported that my dirty fix with the override > of the PersistenceBrokerFactoryDefaultImpl works for them too, so I guess > that you > have some other problem in your code, Robert. (see the followups of the > 'ThreadLocal causing memory leak' post) > > Here a little summary why from my point of view, the use of ThreadLocal is > causing the leak. > Tomcat (and probably other web-servers) seem to have a pool of Thread objects > that are always alive and ready to serve http requests. The Threads sit idle > until > a http request comes in, when the request is served the thread is returned to > the pool and sits idle again. > Now the problem is that these Thread instances are class-loaded and created > by the server's main ClassLoader, if OJB puts instances of any kind in a > ThreadLocal > variable without removing them, a link between classes/objects loaded/created > in the main ClassLoader and the web-application's ClassLoader is created. > These links will remain active and keep the web-app ClassLoader active until > the Thread instaces are garbage collected. However since these Thread > instaces are > never released the links to the web-app class-loaded objects will remain > alive and prevent the web-app ClassLoader to be garbage collected after > unloading the > web-application. If the web-app ClassLoader is not garbage collected then no > static references (singletons, constants,...) will be cleaned and no classes > will > be unloaded. > > Cleaning static references 'manually' will allow garbage collection will free > heap space, but will break system design (a singleton should be a final static > object and not a static one) and more important it will not allow the web-app > ClassLoader to be garbage collected with all the Class objects that have been > loaded. This will lead over time to a even more problematic OutOfMemoryError > in the Perm. Gen. space. > > It is quite a chain reaction that costed me long time to figure out... :( > > if you need more info just ask ;) > if you think that my analysis of the problem is crap, just say so, I am open > to discussion ;) > bye > Danilo > > > Environment: > > > > OJB: 1.0.3 > > JProfiler: 4.0.1 > > Tomcat: 5.0.19 > > JVM: Sun 1.4.2_06-b03 > > > > While profiling our OJB application, we noticed that after we shut it > > down in Tomcat, we had plenty of org.apache.ojb.broker.* and > > org.apache.ojb.metadata.* objects left behind in memory. Using JProfiler > > we tracked it down to several static variables not getting cleared out > > including: > > > > PersistenceBrokerFactoryFactory.singleton > > MetadataManager.singleton > > ...several others... > > > > Does anyone have any suggestions as to how to clean these up properly? I > > looked for destroy methods and couldn't find any. As a test, I > > downloaded the OJB source and added destroy methods to > > PersistenceBrokerFactoryFactory & MetadataManager that I called from a > > context listener and it worked ok. Really, really don't want to do this > > myself. I'm guessing I'm just overlooking some easy way for cleaning > > these up already provided in OJB.
ThreadLocal is considered to be a risk in web applications because of these reasons. So perhaps it might be useful to make that part configurable in OJB. Eg. in web apps OJB could use the ServletContext or the session instead of ThreadLocal to store away data. If there is interest in this, could you perhaps create an issue in JIRA ? I'll have a look into it then. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
