You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "bryan thompson (Created) (JIRA)" <ji...@apache.org> on 2012/01/13 13:52:39 UTC

[jira] [Created] (RIVER-403) DGC leaks threads

DGC leaks threads
-----------------

                 Key: RIVER-403
                 URL: https://issues.apache.org/jira/browse/RIVER-403
             Project: River
          Issue Type: Bug
    Affects Versions: River_2.2.0
            Reporter: bryan thompson


This is from a posting on river-users.  The issue is being filed in response to that thread.

I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 

I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().

Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).

I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Resolved] (RIVER-403) DGC leaks threads

Posted by "Peter Firmstone (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/RIVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Firmstone resolved RIVER-403.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: River_2.2.1
         Assignee: Peter Firmstone

Issue resolved
                
> DGC leaks threads
> -----------------
>
>                 Key: RIVER-403
>                 URL: https://issues.apache.org/jira/browse/RIVER-403
>             Project: River
>          Issue Type: Sub-task
>    Affects Versions: River_2.2.0
>            Reporter: bryan thompson
>            Assignee: Peter Firmstone
>              Labels: DGC, memory_leak
>             Fix For: River_2.2.1
>
>
> This is from a posting on river-users.  The issue is being filed in response to that thread.
> I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 
> I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().
> Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).
> I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RIVER-403) DGC leaks threads

Posted by "Peter Firmstone (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/RIVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203366#comment-13203366 ] 

Peter Firmstone commented on RIVER-403:
---------------------------------------

The fix for this issue was committed in svn revision #1231478
It was accidentally recorded against River-142
                
> DGC leaks threads
> -----------------
>
>                 Key: RIVER-403
>                 URL: https://issues.apache.org/jira/browse/RIVER-403
>             Project: River
>          Issue Type: Bug
>    Affects Versions: River_2.2.0
>            Reporter: bryan thompson
>              Labels: DGC, memory_leak
>
> This is from a posting on river-users.  The issue is being filed in response to that thread.
> I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 
> I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().
> Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).
> I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Closed] (RIVER-403) DGC leaks threads

Posted by "Peter Firmstone (Closed) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/RIVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Firmstone closed RIVER-403.
---------------------------------


Bug fixed.
                
> DGC leaks threads
> -----------------
>
>                 Key: RIVER-403
>                 URL: https://issues.apache.org/jira/browse/RIVER-403
>             Project: River
>          Issue Type: Sub-task
>    Affects Versions: River_2.2.0
>            Reporter: bryan thompson
>            Assignee: Peter Firmstone
>              Labels: DGC, memory_leak
>             Fix For: River_2.2.1
>
>
> This is from a posting on river-users.  The issue is being filed in response to that thread.
> I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 
> I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().
> Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).
> I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (RIVER-403) DGC leaks threads

Posted by "Peter Firmstone (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/RIVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Firmstone updated RIVER-403:
----------------------------------

    Issue Type: Sub-task  (was: Bug)
    Workaround:   (was:  I modified the pattern to return a "thick" future rather than a proxy for the future.  This caused the RMI call to wait on the server until the future was done and then sent back the outcome.  This "fixed" the DGC memory/thread leak by reducing the number of exported proxies dramatically.)
        Parent: RIVER-142
    
> DGC leaks threads
> -----------------
>
>                 Key: RIVER-403
>                 URL: https://issues.apache.org/jira/browse/RIVER-403
>             Project: River
>          Issue Type: Sub-task
>    Affects Versions: River_2.2.0
>            Reporter: bryan thompson
>              Labels: DGC, memory_leak
>             Fix For: River_2.2.1
>
>
> This is from a posting on river-users.  The issue is being filed in response to that thread.
> I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 
> I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().
> Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).
> I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (RIVER-403) DGC leaks threads

Posted by "Peter Firmstone (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/RIVER-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203374#comment-13203374 ] 

Peter Firmstone commented on RIVER-403:
---------------------------------------

The fix was committed under the parent bug id RIVER-142
                
> DGC leaks threads
> -----------------
>
>                 Key: RIVER-403
>                 URL: https://issues.apache.org/jira/browse/RIVER-403
>             Project: River
>          Issue Type: Sub-task
>    Affects Versions: River_2.2.0
>            Reporter: bryan thompson
>            Assignee: Peter Firmstone
>              Labels: DGC, memory_leak
>             Fix For: River_2.2.1
>
>
> This is from a posting on river-users.  The issue is being filed in response to that thread.
> I am seeing what would appear to be one DGC thread allocated per exported object.  This is using River 2.2 and Sun JDK 1.6.0_17.  Relevant configuration parameters are below. 
> I am observing problems with the DGC threads not being retired on a timely basis.  The exported objects are proxies for Futures which are being executed on the service.  The code pattern is such that the proxied Future goes out of lexical scope quite quickly.  E.g., rmiCallReturningProxyForFuture().get().
> Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads.  This turns into a problem for the JVM due to the stack allocation per thread.  Presumably this is not good for other reasons as well (e.g., scheduling).
> I have tried to override the leaseValue and checkInterval defaults per the configuration options below.  I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end.  However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira