[
https://issues.apache.org/activemq/browse/AMQ-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=47483#action_47483
]
rwitcher edited comment on AMQ-1974 at 11/18/08 7:01 AM:
-------------------------------------------------------------
We are experiencing a similar issue using a non-persistent queue and
producerFlowControl with ActiveMQ 5.1.0. After sending enough messages for the
broker to block the producers due to the memory usage being at 100%, we start a
consumer which then drains the queue. However, since the memoryUsage stays at
100%, the broker is still blocking producers from sending more messages.
I have 25 threads producing messages. One is blocked here:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1841)
java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:253)
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:92)
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1176)
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1170)
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java:1743)
org.apache.activemq.ActiveMQMessageProducer.close(ActiveMQMessageProducer.java:147)
org.springframework.jms.support.JmsUtils.closeMessageProducer(JmsUtils.java:124)
org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:519)
org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:477)
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:428)
org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:475)
The rest are blocked here
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:39)
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1176)
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1170)
org.apache.activemq.ActiveMQSession.<init>(ActiveMQSession.java:190)
org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:296)
sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.springframework.jms.connection.SingleConnectionFactory$SharedConnectionInvocationHandler.invoke(SingleConnectionFactory.java:418)
$Proxy30.createSession(Unknown Source)
org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:419)
org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:475)
was (Author: rwitcher):
We are experiencing a similar issue using a non-persistent queue and
producerFlowControl with ActiveMQ 5.1.0. After sending enough messages for the
broker to block the producers due to the memory usage being at 100%, we start a
consumer which then drains the queue. However, since the memoryUsage stays at
100%, the broker is still blocking producers from sending more messages.
All of the producer threads appear to be blocked here:
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:39)
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnection.java:1176)
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnection.java:1170)
org.apache.activemq.ActiveMQSession.<init>(ActiveMQSession.java:190)
org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:296)
sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:585)
org.springframework.jms.connection.SingleConnectionFactory$SharedConnectionInvocationHandler.invoke(SingleConnectionFactory.java:418)
$Proxy30.createSession(Unknown Source)
org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:200)
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:419)
org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:475)
> MemoryUsage stays at 100% used forever after all messages are sent
> ------------------------------------------------------------------
>
> Key: AMQ-1974
> URL: https://issues.apache.org/activemq/browse/AMQ-1974
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.1.0
> Environment: Linux with 2.6.18 kernel
> JDK 1.5.0_15
> Reporter: Neal Yin
> Priority: Critical
> Attachments: MsgsPerSecond.diff, TryJmsClient.java, TryJmsManager.java
>
>
> We use a network of brokers and topic to do messaging. All our message
> producers and consumers talk to the local VM broker. We reply on bridges
> between network of brokers to move messages between brokers. We found a case
> that MemoryUsage stays at 100% forever after all messages are sent.
> I attached two files to show this memory leak problem. TryJmsClient keeps
> sending persistent messages to a Topic. TryJmsManager has a message consumer.
> Start TryJmsManager first and then start TryJmsClient. After running about 10
> seconds, TryJmsClient stops sending because of getting "SystemUsage memory
> limit reached" error. About 24K messages are sent and consumer shows it get
> all messages. Now examine ActiveMQ MemoryUsage printout of TryJmsClient,
> MemoryUsage percentage stays at 100% or 99% forever. Producer can never send
> any more messages.
> Note1: If I slow down sending by adding a sleep, I don't see memory leak
> immediately. I am not sure for longer running time.
> Note2: If I use Queue instead of Topic, there is no memory leak.
> Note3: This looks like similar to AMQ-1833 that is fixed in 5.2. But after
> testing with 5.2 snapshot, I still get the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
