If you can reproduce the circumstances when connections get leaked, even
if it takes a whole day or two, it might be worth trying this:
Instrument the methods in the org.dspace.core.Context class that
allocate and free JDBC connections. When a connection is obtained,
add a little code to make a log entry that includes a unique identifier
of the Context (e.g. its hashcode, or toString()) *and* at least a few
levels of stack trace so you'll be able to tell what the overall context
(so to speak) is. Then, when the JDBC connection is freed, log the
same unique identifier of the context.
At the end of the test period, you'll be able to reconcile all the
allocate and free operations and see if there are any explicit Context
leaks.
I did something similar at one point trying to track down a warning that
was logged occasionally about using a closed JDBC connection, but only
found that sometimes a Context gets closed more than once. This is
relatively harmless, so I left it alone.
-- Larry
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
