jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2768) Finalize method on SessionImpl
Date Fri, 08 Oct 2010 10:35:31 GMT

    [ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919217#action_12919217

Jukka Zitting commented on JCR-2768:

Hmm, forget that, the reference is no longer available when a weak reference is enqueued.

However, note that with the SessionContext object we've already gone a long way towards detaching
SessionImpl from the internals it uses. Thus it might be possible to do something like changing
the activeSessions map to a IdentityHashMap<WeakReference<SessionImpl>, SessionContext>
so we could use an enqueued weak reference to still access and close the context of the garbage-collected

Note that such a solution would only be useful if a normal Session.logout() would drop the
weak reference and cause the JVM not to track it anymore, as otherwise I believe the overhead
is just the same as with a finalizer.

> Finalize method on SessionImpl
> ------------------------------
>                 Key: JCR-2768
>                 URL: https://issues.apache.org/jira/browse/JCR-2768
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-core
>    Affects Versions: 2.1.0
>            Reporter: Douglas Britsch
> Doing some profiling on our application which uses Jackrabbit-2.1.0 I 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 ).
> Per Jukka's suggestion on the mailing list "
> 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."

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message