You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Trevor Pounds (JIRA)" <ji...@apache.org> on 2008/02/19 22:00:15 UTC
[jira] Created: (SM-1234) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
---------------------------------------------------------------------------------------
Key: SM-1234
URL: https://issues.apache.org/activemq/browse/SM-1234
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jms
Affects Versions: 3.2.1
Reporter: Trevor Pounds
Fix For: 3.3
There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
Possible fixes:
1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SMXCOMP-96) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SMXCOMP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Baptiste Onofré updated SMXCOMP-96:
----------------------------------------
Fix Version/s: (was: servicemix-jms-2010.01)
servicemix-jms-2010.02
> ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
> ---------------------------------------------------------------------------------------
>
> Key: SMXCOMP-96
> URL: https://issues.apache.org/activemq/browse/SMXCOMP-96
> Project: ServiceMix Components
> Issue Type: Bug
> Components: servicemix-jms
> Affects Versions: 3.2.1
> Reporter: Trevor Pounds
> Fix For: servicemix-jms-2010.02
>
>
> There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
> Possible fixes:
> 1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
> 2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SMXCOMP-96) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
Posted by "Lars Heinemann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SMXCOMP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Heinemann updated SMXCOMP-96:
----------------------------------
Fix Version/s: (was: servicemix-jms-2009.01)
servicemix-jms-2009.02
> ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
> ---------------------------------------------------------------------------------------
>
> Key: SMXCOMP-96
> URL: https://issues.apache.org/activemq/browse/SMXCOMP-96
> Project: ServiceMix Components
> Issue Type: Bug
> Components: servicemix-jms
> Affects Versions: 3.2.1
> Reporter: Trevor Pounds
> Fix For: servicemix-jms-2009.02
>
>
> There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
> Possible fixes:
> 1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
> 2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SMXCOMP-96) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
Posted by "Gert Vanthienen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SMXCOMP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gert Vanthienen updated SMXCOMP-96:
-----------------------------------
Fix Version/s: (was: servicemix-jms-2009.02)
servicemix-jms-2010.01
> ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
> ---------------------------------------------------------------------------------------
>
> Key: SMXCOMP-96
> URL: https://issues.apache.org/activemq/browse/SMXCOMP-96
> Project: ServiceMix Components
> Issue Type: Bug
> Components: servicemix-jms
> Affects Versions: 3.2.1
> Reporter: Trevor Pounds
> Fix For: servicemix-jms-2010.01
>
>
> There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
> Possible fixes:
> 1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
> 2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1234) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
Posted by "Trevor Pounds (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43664#action_43664 ]
Trevor Pounds commented on SM-1234:
-----------------------------------
I noticed that there is a way to disable caching of message attributes when using the Spring based jms:consumer endpoint with the "stateless" attribute set to true.
> ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
> ---------------------------------------------------------------------------------------
>
> Key: SM-1234
> URL: https://issues.apache.org/activemq/browse/SM-1234
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
> Affects Versions: 3.2.1
> Reporter: Trevor Pounds
> Fix For: 3.3
>
>
> There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
> Possible fixes:
> 1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
> 2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-1234) ServiceMix JMS
MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
Posted by "Freeman Fang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/SM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Freeman Fang updated SM-1234:
-----------------------------
Fix Version/s: 3.3.1
3.4
(was: 3.3)
> ServiceMix JMS MultiplexingConsumerProcessor memory bloat due to hung/delayed exchanges
> ---------------------------------------------------------------------------------------
>
> Key: SM-1234
> URL: https://issues.apache.org/activemq/browse/SM-1234
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
> Affects Versions: 3.2.1
> Reporter: Trevor Pounds
> Fix For: 3.3.1, 3.4
>
>
> There is a pendingMessages data structure which holds onto JMS Message object references until the exchange is returned. If the asynchronous exchanges are hung or delayed the pendingMessages can grow quite large resulting in heap allocation errors if the messages are large. A heap dump on one of our data sets showed > 700MB of messages being referenced due to this data structure. As far as I can tell the JMS Message reference pulled from the map is only used to retrieve certain JMS Message properties (getJMSReplyTo, getJMSMessageID, getJMSCorrelationID).
> Possible fixes:
> 1) On InOnly exchanges do not store the Message since the method exits without using any of the message attributes
> 2) Store only the attributes needed for exchanges needing a reply
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.