Hi Danilo,
sorry for the delay, last week I had problems with my apache account.
I started work on this issue and will add a shutdown method in PBF class
and associated interface for OJB 1.0.x branch. As Tom mentioned in his
last post, creating a jira issue will be helpful.
regards,
Armin
Danilo Tommasina 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.
Any suggestions?
Thanks.
Bob Glugla
Boeing
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
