You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by greenbean <Ke...@ngc.com> on 2008/02/05 19:34:11 UTC
ActiveMQ 4.11 Memory Leak?
We have suddenly run into a problem with our server running out of heap
space. When I look at the hprof file generated, I see alot of activemq data
hanging around. Is this normal? It almost looks like the messages are not
getting garbage collected after sent. This worked fine in the past. We
have not change anything recently except for deploying some new application
code. Any ideas what could cause this?
Here is a snip from JHAT showing a reference to an ActiveMQObjectMessage.
There are lots of these.
--> org.apache.activemq.transport.tcp.TcpTransport@0x5fc5c078 (91 bytes)
(field transportListener:)
--> org.apache.activemq.transport.InactivityMonitor@0x5fc5c040 (56 bytes)
(field transportListener:)
--> org.apache.activemq.transport.WireFormatNegotiator@0x5fc5c010 (44 bytes)
(field transportListener:)
--> org.apache.activemq.transport.failover.FailoverTransport$1@0x5fc687f8
(12 bytes) (field this$0:)
--> org.apache.activemq.transport.failover.FailoverTransport@0x5fc4b8e0 (97
bytes) (field stateTracker:)
--> org.apache.activemq.state.ConnectionStateTracker@0x5fc4ba58 (17 bytes)
(field connectionStates:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4ba70
(44 bytes) (field segments:)
-->
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment;@0x5fc4baa0
(72 bytes) (Element 11 of
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment;@0x5fc4baa0:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment@0x5fc4bbf0
(32 bytes) (field table:)
-->
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry;@0x5fc4bc20
(12 bytes) (Element 0 of
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry;@0x5fc4bc20:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry@0x5fc4bc30
(24 bytes) (field value:)
--> org.apache.activemq.state.ConnectionState@0x5fc4bcc8 (28 bytes) (field
transactions:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4bd90
(44 bytes) (field segments:)
-->
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment;@0x5fc4bdc0
(72 bytes) (Element 9 of
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment;@0x5fc4bdc0:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$Segment@0x5fc4bf30
(32 bytes) (field table:)
-->
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry;@0xb38b02e8
(2056 bytes) (Element 89 of
[Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry;@0xb38b02e8:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry@0xbd7155a8
(24 bytes) (field next:)
-->
edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap$HashEntry@0x8dbed698
(24 bytes) (field value:)
--> org.apache.activemq.state.TransactionState@0x69310770 (25 bytes) (field
commands:)
--> java.util.ArrayList@0x69310790 (20 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x693107a8 (48 bytes) (Element 0 of
[Ljava.lang.Object;@0x693107a8:)
--> org.apache.activemq.command.ActiveMQObjectMessage@0x69310808 (162 bytes)
--
View this message in context: http://www.nabble.com/ActiveMQ-4.11-Memory-Leak--tp15296611s2354p15296611.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: ActiveMQ 4.11 Memory Leak?
Posted by greenbean <Ke...@ngc.com>.
I am having some trouble recreating it right now. Are there any tips you
could provide by viewing the reference from root to the message (shown
below)? Could this show that activemq is keeping references to the messages
because there is something wrong with transaction commits?
We recently modified the Hibernate transaction configuration. Originally we
were using a Jboss Hibernate MBean that set transaction properties to use
JTA for us. Everything worked fine. We moved away from using the Jboss
MBean to configuring Hibernate in Spring. When we did this, we forgot to
set the JTA properties explicitly and had some issues with Hibernate. We
then added the JTA configuration back in as shown below.
<prop key="hibernate.transaction.factory_class">
org.hibernate.transaction.JTATransactionFactory
</prop>
<prop key="hibernate.transaction.manager_lookup_class">
org.hibernate.transaction.JBossTransactionManagerLookup
</prop>
ActiveMQ and Hibernate work with the same transaction. Could this be
causing issues?
rajdavies wrote:
>
> It will is difficult to determine without more information - is it
> possible to generate a test case ?
>
> On Feb 5, 2008, at 6:34 PM, greenbean wrote:
>
>>
>> We have suddenly run into a problem with our server running out of
>> heap
>> space. When I look at the hprof file generated, I see alot of
>> activemq data
>> hanging around. Is this normal? It almost looks like the messages
>> are not
>> getting garbage collected after sent. This worked fine in the
>> past. We
>> have not change anything recently except for deploying some new
>> application
>> code. Any ideas what could cause this?
>>
>> Here is a snip from JHAT showing a reference to an
>> ActiveMQObjectMessage.
>> There are lots of these.
>>
>> --> org.apache.activemq.transport.tcp.TcpTransport@0x5fc5c078 (91
>> bytes)
>> (field transportListener:)
>> --> org.apache.activemq.transport.InactivityMonitor@0x5fc5c040 (56
>> bytes)
>> (field transportListener:)
>> --> org.apache.activemq.transport.WireFormatNegotiator@0x5fc5c010
>> (44 bytes)
>> (field transportListener:)
>> --> org.apache.activemq.transport.failover.FailoverTransport
>> $1@0x5fc687f8
>> (12 bytes) (field this$0:)
>> -->
>> org.apache.activemq.transport.failover.FailoverTransport@0x5fc4b8e0
>> (97
>> bytes) (field stateTracker:)
>> --> org.apache.activemq.state.ConnectionStateTracker@0x5fc4ba58 (17
>> bytes)
>> (field connectionStates:)
>> -->
>> edu
>> .emory
>> .mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4ba70
>> (44 bytes) (field segments:)
>> -->
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment;@0x5fc4baa0
>> (72 bytes) (Element 11 of
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment;@0x5fc4baa0:)
>> -->
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment@0x5fc4bbf0
>> (32 bytes) (field table:)
>> -->
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry;@0x5fc4bc20
>> (12 bytes) (Element 0 of
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry;@0x5fc4bc20:)
>> -->
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry@0x5fc4bc30
>> (24 bytes) (field value:)
>> --> org.apache.activemq.state.ConnectionState@0x5fc4bcc8 (28 bytes)
>> (field
>> transactions:)
>> -->
>> edu
>> .emory
>> .mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4bd90
>> (44 bytes) (field segments:)
>> -->
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment;@0x5fc4bdc0
>> (72 bytes) (Element 9 of
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment;@0x5fc4bdc0:)
>> -->
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $Segment@0x5fc4bf30
>> (32 bytes) (field table:)
>> -->
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry;@0xb38b02e8
>> (2056 bytes) (Element 89 of
>> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry;@0xb38b02e8:)
>> -->
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry@0xbd7155a8
>> (24 bytes) (field next:)
>> -->
>> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
>> $HashEntry@0x8dbed698
>> (24 bytes) (field value:)
>> --> org.apache.activemq.state.TransactionState@0x69310770 (25 bytes)
>> (field
>> commands:)
>> --> java.util.ArrayList@0x69310790 (20 bytes) (field elementData:)
>> --> [Ljava.lang.Object;@0x693107a8 (48 bytes) (Element 0 of
>> [Ljava.lang.Object;@0x693107a8:)
>> --> org.apache.activemq.command.ActiveMQObjectMessage@0x69310808
>> (162 bytes)
>> --
>> View this message in context:
>> http://www.nabble.com/ActiveMQ-4.11-Memory-Leak--tp15296611s2354p15296611.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/ActiveMQ-4.11-Memory-Leak--tp15296611s2354p15306724.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: ActiveMQ 4.11 Memory Leak?
Posted by Rob Davies <ra...@gmail.com>.
It will is difficult to determine without more information - is it
possible to generate a test case ?
On Feb 5, 2008, at 6:34 PM, greenbean wrote:
>
> We have suddenly run into a problem with our server running out of
> heap
> space. When I look at the hprof file generated, I see alot of
> activemq data
> hanging around. Is this normal? It almost looks like the messages
> are not
> getting garbage collected after sent. This worked fine in the
> past. We
> have not change anything recently except for deploying some new
> application
> code. Any ideas what could cause this?
>
> Here is a snip from JHAT showing a reference to an
> ActiveMQObjectMessage.
> There are lots of these.
>
> --> org.apache.activemq.transport.tcp.TcpTransport@0x5fc5c078 (91
> bytes)
> (field transportListener:)
> --> org.apache.activemq.transport.InactivityMonitor@0x5fc5c040 (56
> bytes)
> (field transportListener:)
> --> org.apache.activemq.transport.WireFormatNegotiator@0x5fc5c010
> (44 bytes)
> (field transportListener:)
> --> org.apache.activemq.transport.failover.FailoverTransport
> $1@0x5fc687f8
> (12 bytes) (field this$0:)
> -->
> org.apache.activemq.transport.failover.FailoverTransport@0x5fc4b8e0
> (97
> bytes) (field stateTracker:)
> --> org.apache.activemq.state.ConnectionStateTracker@0x5fc4ba58 (17
> bytes)
> (field connectionStates:)
> -->
> edu
> .emory
> .mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4ba70
> (44 bytes) (field segments:)
> -->
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment;@0x5fc4baa0
> (72 bytes) (Element 11 of
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment;@0x5fc4baa0:)
> -->
> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment@0x5fc4bbf0
> (32 bytes) (field table:)
> -->
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry;@0x5fc4bc20
> (12 bytes) (Element 0 of
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry;@0x5fc4bc20:)
> -->
> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry@0x5fc4bc30
> (24 bytes) (field value:)
> --> org.apache.activemq.state.ConnectionState@0x5fc4bcc8 (28 bytes)
> (field
> transactions:)
> -->
> edu
> .emory
> .mathcs.backport.java.util.concurrent.ConcurrentHashMap@0x5fc4bd90
> (44 bytes) (field segments:)
> -->
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment;@0x5fc4bdc0
> (72 bytes) (Element 9 of
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment;@0x5fc4bdc0:)
> -->
> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $Segment@0x5fc4bf30
> (32 bytes) (field table:)
> -->
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry;@0xb38b02e8
> (2056 bytes) (Element 89 of
> [Ledu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry;@0xb38b02e8:)
> -->
> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry@0xbd7155a8
> (24 bytes) (field next:)
> -->
> edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
> $HashEntry@0x8dbed698
> (24 bytes) (field value:)
> --> org.apache.activemq.state.TransactionState@0x69310770 (25 bytes)
> (field
> commands:)
> --> java.util.ArrayList@0x69310790 (20 bytes) (field elementData:)
> --> [Ljava.lang.Object;@0x693107a8 (48 bytes) (Element 0 of
> [Ljava.lang.Object;@0x693107a8:)
> --> org.apache.activemq.command.ActiveMQObjectMessage@0x69310808
> (162 bytes)
> --
> View this message in context: http://www.nabble.com/ActiveMQ-4.11-Memory-Leak--tp15296611s2354p15296611.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>