Sure, sounds good. Let me dig into it a bit. Should I create an issue in the mean time? Thanks, Doug
On Oct 5, 2010, at 3:15 PM, Jukka Zitting wrote: > Hi, > > On Tue, Oct 5, 2010 at 11:46 PM, Doug Britsch > <[email protected]> wrote: >> I was doing some profiling on our application which uses Jackrabbit-2.1.0 >> and noticed that there were an awful lot of java.lang.ref.Finalizer objects >> hanging around. Digging around I found the culprit was a finalize method on >> SessionImpl. While I can see what it is trying to do (close the session if >> you have not called logout) , I have found in the past that on application >> servers, finalize should be avoided for objects that are created and deleted >> frequently, as the GC behavior and object allocation is severely impacted, >> and because of the number of references held by the session this seems like >> it could keep a lot more in memory than needed a lot longer. (for more info >> see http://www.fasterj.com/articles/finalizer1.shtml ). What are your >> thoughts on refactoring this bit of code. > > The automatic closing of a discarded session and related the warning > message are pretty useful in practice, as there are quite a few > session leaks in many client applications. So I'd rather keep that > functionality. > > If the finalizer causes problems, we could investigate using weak (or > perhaps phantom) references and a reference queue for this purpose. > The RepositoryImpl class already keeps weak references to all sessions > in the activeSessions map, so this shouldn't even be too difficult to > implement. > > Would you be interested in drafting a patch for something like this? > > BR, > > Jukka Zitting > This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
