You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Douglas Britsch (JIRA)" <ji...@apache.org> on 2010/10/06 00:58:33 UTC
[jira] Created: (JCR-2768) Finalize method on SessionImpl
Finalize method on SessionImpl
------------------------------
Key: JCR-2768
URL: https://issues.apache.org/jira/browse/JCR-2768
Project: Jackrabbit Content Repository
Issue Type: Improvement
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.
[jira] Commented: (JCR-2768) Finalize method on SessionImpl
Posted by "Douglas Britsch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918643#action_12918643 ]
Douglas Britsch commented on JCR-2768:
--------------------------------------
I did some investigation into using phantom references to track abandon sessions instead of the finalize method used currently. Unfortunately keeping references to the sessions them selfs will not work, as they have been GC'd when I am notified and I am unable to call logout for obvious reasons. I looked a bit into using proxy objects for the SessionImpl, and that is workable with a little overhead, but would require using cglib as there are quite a lot of uses of the public methods on the concrete SessionImpl class. So there seems to be four options here:
1. leave as is and take the GC hit in well behaved applications
2. Use phantom references to the SessionImpl and log a warning when we detect an abandon session, but dont logout the session.
3. Do some refactoring and extract an interface for the public methods of SessionImpl, then use the jdk's Proxy as the object we hand out. Thus allowing us to cleanup the real SesionImpl when the proxy is no longer referenced.
4. Same as above, but introduce cglib and proxy the current concrete SessionImpl.
??
Thoughts?
> 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.
[jira] Commented: (JCR-2768) Finalize method on SessionImpl
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ 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 session.
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.
[jira] Updated: (JCR-2768) Finalize method on SessionImpl
Posted by "Douglas Britsch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Douglas Britsch updated JCR-2768:
---------------------------------
Component/s: jackrabbit-core
Affects Version/s: 2.1.0
> 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.
[jira] Commented: (JCR-2768) Finalize method on SessionImpl
Posted by "Julian Sedding (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918819#action_12918819 ]
Julian Sedding commented on JCR-2768:
-------------------------------------
You may want to have a look at the GhostReference described in an old javaspecialist.eu newsletter issue[0]. It's been a while since I read it, so I don't recall the details, but I think it might be helpful. The approach would be similar to your second point.
[0] http://www.javaspecialists.eu/archive/Issue098.html
> 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.
[jira] Commented: (JCR-2768) Finalize method on SessionImpl
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918840#action_12918840 ]
Jukka Zitting commented on JCR-2768:
------------------------------------
Could we use weak references instead of phantom references? When a weak reference is queued for destruction, you can still access the referenced object. It probably still comes with similar (if not worse) garbage collection overhead as a finalizer, but perhaps clearing the reference when a normal logout() is called would avoid that.
> 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.