From dev-return-29546-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Oct 05 22:58:58 2010 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 37673 invoked from network); 5 Oct 2010 22:58:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Oct 2010 22:58:58 -0000 Received: (qmail 99296 invoked by uid 500); 5 Oct 2010 22:58:58 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 99266 invoked by uid 500); 5 Oct 2010 22:58:57 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 99258 invoked by uid 99); 5 Oct 2010 22:58:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Oct 2010 22:58:57 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Oct 2010 22:58:55 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o95MwXCG028075 for ; Tue, 5 Oct 2010 22:58:33 GMT Message-ID: <6928009.562191286319513272.JavaMail.jira@thor> Date: Tue, 5 Oct 2010 18:58:33 -0400 (EDT) From: "Douglas Britsch (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Created: (JCR-2768) Finalize method on SessionImpl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org 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.