[jira] Updated: (JCRRMI-28) Leaking ServerEvent objects after RMI connection loss
[ https://issues.apache.org/jira/browse/JCRRMI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Theess updated JCRRMI-28: -- Attachment: jcr-rmi.patch This patch fixes the issue. By implementing the Unreferenced interface, ServerSession is notified after java.rmi.dgc.leaseValue expires, and logs itself out. At this point, no new instances of ServerEventCollection$ServerEvent are created for this session. Leaking ServerEvent objects after RMI connection loss - Key: JCRRMI-28 URL: https://issues.apache.org/jira/browse/JCRRMI-28 Project: Jackrabbit JCR-RMI Issue Type: Bug Affects Versions: 1.6.0, 2.1.0 Environment: Windows 7 Pro x64 32Bit Java VM java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) Reporter: Jens Theess Attachments: jcr-rmi.patch, RMI-Test.zip When an RMI connection is crashes, or the client is terminated without calling session.logout(), the server leaks ServerEventCollection$ServerEvent objects. Attached is a zip with two java programs that demonstrate the behaviour. Steps to reproduce: * Open a cmd shell * cd jcrserver * mvn compile * SET MAVEN_OPTS=-Djava.rmi.dgc.leaseValue=1 mvn exec:java -Dexec.mainClass=RMIServer * Open another cmd shell * cd jcrrmiclient * mvn compile * mvn exec:java -Dexec.mainClass=RMIClient Watch the heap: * Start VisualVM (you'll need the VisualVM-Sampler plugin) * Go to the RMIServer process. * Open the Sampler tab and sample Memory. * In the filter enter ServerEvent. You'll now see the number of ServerEvents (also _Stub and _Skel) steadily increasing. * Quit the RMIClient using Ctrl-C. The number of ServerEvents is still increasing, even after the RMI lease time expires. If, instead of being killed, the client calls session.logout(), the server stops producing new ServerEvent instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCRRMI-28) Leaking ServerEvent objects after RMI connection loss
[ https://issues.apache.org/jira/browse/JCRRMI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12875532#action_12875532 ] Jens Theess edited comment on JCRRMI-28 at 6/4/10 4:58 AM: --- This patch for 1.5.7 fixes the issue. By implementing the Unreferenced interface, ServerSession is notified after java.rmi.dgc.leaseValue expires, and logs itself out. At this point, no new instances of ServerEventCollection$ServerEvent are created for this session. was (Author: jenstheess): This patch fixes the issue. By implementing the Unreferenced interface, ServerSession is notified after java.rmi.dgc.leaseValue expires, and logs itself out. At this point, no new instances of ServerEventCollection$ServerEvent are created for this session. Leaking ServerEvent objects after RMI connection loss - Key: JCRRMI-28 URL: https://issues.apache.org/jira/browse/JCRRMI-28 Project: Jackrabbit JCR-RMI Issue Type: Bug Affects Versions: 1.6.0, 2.1.0 Environment: Windows 7 Pro x64 32Bit Java VM java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) Reporter: Jens Theess Attachments: jcr-rmi.patch, RMI-Test.zip When an RMI connection is crashes, or the client is terminated without calling session.logout(), the server leaks ServerEventCollection$ServerEvent objects. Attached is a zip with two java programs that demonstrate the behaviour. Steps to reproduce: * Open a cmd shell * cd jcrserver * mvn compile * SET MAVEN_OPTS=-Djava.rmi.dgc.leaseValue=1 mvn exec:java -Dexec.mainClass=RMIServer * Open another cmd shell * cd jcrrmiclient * mvn compile * mvn exec:java -Dexec.mainClass=RMIClient Watch the heap: * Start VisualVM (you'll need the VisualVM-Sampler plugin) * Go to the RMIServer process. * Open the Sampler tab and sample Memory. * In the filter enter ServerEvent. You'll now see the number of ServerEvents (also _Stub and _Skel) steadily increasing. * Quit the RMIClient using Ctrl-C. The number of ServerEvents is still increasing, even after the RMI lease time expires. If, instead of being killed, the client calls session.logout(), the server stops producing new ServerEvent instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-28) Leaking ServerEvent objects after RMI connection loss
[ https://issues.apache.org/jira/browse/JCRRMI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Theess updated JCRRMI-28: -- Status: Patch Available (was: Open) Fix Version/s: 1.6.0 The patch fixes the issue for jackrabbit-jcr-rmi 1.5.0. It can trivially be ported to 2.1.0. Leaking ServerEvent objects after RMI connection loss - Key: JCRRMI-28 URL: https://issues.apache.org/jira/browse/JCRRMI-28 Project: Jackrabbit JCR-RMI Issue Type: Bug Affects Versions: 1.6.0, 2.1.0 Environment: Windows 7 Pro x64 32Bit Java VM java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) Reporter: Jens Theess Fix For: 1.6.0 Attachments: jcr-rmi.patch, RMI-Test.zip When an RMI connection is crashes, or the client is terminated without calling session.logout(), the server leaks ServerEventCollection$ServerEvent objects. Attached is a zip with two java programs that demonstrate the behaviour. Steps to reproduce: * Open a cmd shell * cd jcrserver * mvn compile * SET MAVEN_OPTS=-Djava.rmi.dgc.leaseValue=1 mvn exec:java -Dexec.mainClass=RMIServer * Open another cmd shell * cd jcrrmiclient * mvn compile * mvn exec:java -Dexec.mainClass=RMIClient Watch the heap: * Start VisualVM (you'll need the VisualVM-Sampler plugin) * Go to the RMIServer process. * Open the Sampler tab and sample Memory. * In the filter enter ServerEvent. You'll now see the number of ServerEvents (also _Stub and _Skel) steadily increasing. * Quit the RMIClient using Ctrl-C. The number of ServerEvents is still increasing, even after the RMI lease time expires. If, instead of being killed, the client calls session.logout(), the server stops producing new ServerEvent instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-28) Leaking ServerEvent objects after RMI connection loss
Leaking ServerEvent objects after RMI connection loss - Key: JCRRMI-28 URL: https://issues.apache.org/jira/browse/JCRRMI-28 Project: Jackrabbit JCR-RMI Issue Type: Bug Affects Versions: 1.6.0, 2.1.0 Environment: Windows 7 Pro x64 32Bit Java VM java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) Reporter: Jens Theess Attachments: RMI-Test.zip When an RMI connection is crashes, or the client is terminated without calling session.logout(), the server leaks ServerEventCollection$ServerEvent objects. Attached is a zip with two java programs that demonstrate the behaviour. Steps to reproduce: * Open a cmd shell * cd jcrserver * mvn compile * SET MAVEN_OPTS=-Djava.rmi.dgc.leaseValue=1 mvn exec:java -Dexec.mainClass=RMIServer * Open another cmd shell * cd jcrrmiclient * mvn compile * mvn exec:java -Dexec.mainClass=RMIClient Watch the heap: * Start VisualVM (you'll need the VisualVM-Sampler plugin) * Go to the RMIServer process. * Open the Sampler tab and sample Memory. * In the filter enter ServerEvent. You'll now see the number of ServerEvents (also _Stub and _Skel) steadily increasing. * Quit the RMIClient using Ctrl-C. The number of ServerEvents is still increasing, even after the RMI lease time expires. If, instead of being killed, the client calls session.logout(), the server stops producing new ServerEvent instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCRRMI-28) Leaking ServerEvent objects after RMI connection loss
[ https://issues.apache.org/jira/browse/JCRRMI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Theess updated JCRRMI-28: -- Attachment: RMI-Test.zip Leaking ServerEvent objects after RMI connection loss - Key: JCRRMI-28 URL: https://issues.apache.org/jira/browse/JCRRMI-28 Project: Jackrabbit JCR-RMI Issue Type: Bug Affects Versions: 1.6.0, 2.1.0 Environment: Windows 7 Pro x64 32Bit Java VM java version 1.6.0_20 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing) Reporter: Jens Theess Attachments: RMI-Test.zip When an RMI connection is crashes, or the client is terminated without calling session.logout(), the server leaks ServerEventCollection$ServerEvent objects. Attached is a zip with two java programs that demonstrate the behaviour. Steps to reproduce: * Open a cmd shell * cd jcrserver * mvn compile * SET MAVEN_OPTS=-Djava.rmi.dgc.leaseValue=1 mvn exec:java -Dexec.mainClass=RMIServer * Open another cmd shell * cd jcrrmiclient * mvn compile * mvn exec:java -Dexec.mainClass=RMIClient Watch the heap: * Start VisualVM (you'll need the VisualVM-Sampler plugin) * Go to the RMIServer process. * Open the Sampler tab and sample Memory. * In the filter enter ServerEvent. You'll now see the number of ServerEvents (also _Stub and _Skel) steadily increasing. * Quit the RMIClient using Ctrl-C. The number of ServerEvents is still increasing, even after the RMI lease time expires. If, instead of being killed, the client calls session.logout(), the server stops producing new ServerEvent instances. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
