You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Martin Carpella (JIRA)" <ji...@apache.org> on 2011/05/11 20:15:47 UTC
[jira] [Created] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Memory leak in ConnectionStateTracker with MessagePull objects
--------------------------------------------------------------
Key: AMQ-3316
URL: https://issues.apache.org/jira/browse/AMQ-3316
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.5.0, 5.4.2
Reporter: Martin Carpella
Attachments: connectionstatetracker.patch
We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully reassigned AMQ-3316:
-------------------------------
Assignee: Gary Tully
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Attachments: connectionstatetracker.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Martin Carpella (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031956#comment-13031956 ]
Martin Carpella commented on AMQ-3316:
--------------------------------------
Sorry, I noticed a typo in the patch. Of course it should be "instanceof" instead of "instance of" :/ My bad, please fix this as well.
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: connectionstatetracker.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Martin Carpella (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Carpella updated AMQ-3316:
---------------------------------
Attachment: (was: connectionstatetracker.patch)
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: connectionstatetracker_fixed.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Martin Carpella (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Carpella updated AMQ-3316:
---------------------------------
Attachment: connectionstatetracker_fixed.patch
connectionstatetracker_fixed.patch
Attached new patch with fixed typo.
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: connectionstatetracker_fixed.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Martin Carpella (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Carpella updated AMQ-3316:
---------------------------------
Attachment: (was: connectionstatetracker_fixed.patch)
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: connectionstatetracker_fixed.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Martin Carpella (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Carpella updated AMQ-3316:
---------------------------------
Attachment: connectionstatetracker.patch
Patch with proposed fix for the issue. Applies to both 5.4.2 and 5.5.0.
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Attachments: connectionstatetracker.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-3316) Memory leak in ConnectionStateTracker
with MessagePull objects
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved AMQ-3316.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.6.0
patch applied with thanks in http://svn.apache.org/viewvc?rev=1102018&view=rev
great catch :-)
> Memory leak in ConnectionStateTracker with MessagePull objects
> --------------------------------------------------------------
>
> Key: AMQ-3316
> URL: https://issues.apache.org/jira/browse/AMQ-3316
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.4.2, 5.5.0
> Reporter: Martin Carpella
> Assignee: Gary Tully
> Fix For: 5.6.0
>
> Attachments: connectionstatetracker.patch
>
>
> We discovered a memory leak in {{ConnectionStateTracker}} in case a long-lived connection with prefetch=0 is used.
> If prefetch=0 is used, {{MessagePull}} objects are enqueued in {{messageCache}} with an estimated size of 400. But in the cache's {{removeEldestEntry()}} method no size is subtracted from {{currentCacheSize}} for {{MessagePull}} instances. This messes with the cache as it will continue to remove objects even if there is space in the cache. But after about 5,368,709 consumed messages this will cause the {{currentCacheSize}} to roll-over maximum integer and become negative. As a consequence, for the next about 5,368,709 no messages will be removed from the cache any longer.
> This sooner or later will trigger out-of-memory conditions, depending on the size of the various pools. In our case this caused out-of-memory in PermGen first, as message IDs seem to be internalized, and PermGen is considerably smaller than the heap.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira