You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Christopher L. Shannon (JIRA)" <ji...@apache.org> on 2016/02/13 14:15:18 UTC
[jira] [Closed] (AMQ-5527) Performance issues for
org.apache.activemq.broker.jmx.QueueView.removeMessage
[ https://issues.apache.org/jira/browse/AMQ-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher L. Shannon closed AMQ-5527.
---------------------------------------
Resolution: Duplicate
I believe this issue was fixed in AMQ-6066, I recommend re-testing to see if a newer version that contains that fix indeed helps in this case.
> Performance issues for org.apache.activemq.broker.jmx.QueueView.removeMessage
> -----------------------------------------------------------------------------
>
> Key: AMQ-5527
> URL: https://issues.apache.org/jira/browse/AMQ-5527
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMX
> Affects Versions: 5.10.0
> Environment: Mac/Linux
> Reporter: Michael Rimov
> Priority: Minor
> Labels: performance
>
> On large, persistent queues, (100,000+ messages), we're noticing huge performance issues with Queue.removeMessage(). (It takes 8-20 minutes to remove a single message).
> Thread dump while running showed this:
> "RMI TCP Connection(5)-192.168.1.10" daemon prio=5 tid=0x00007f8491954800 nid=0x9807 runnable [0x000000011bfd7000]
> java.lang.Thread.State: RUNNABLE
> at org.apache.activemq.broker.region.cursors.OrderedPendingList.contains(OrderedPendingList.java:144)
> at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1913)
> at org.apache.activemq.broker.region.Queue.doPageIn(Queue.java:1901)
> at org.apache.activemq.broker.region.Queue.removeMatchingMessages(Queue.java:1374)
> at org.apache.activemq.broker.region.Queue.removeMessage(Queue.java:1341)
> at org.apache.activemq.broker.jmx.QueueView.removeMessage(QueueView.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at javax.management.StandardMBean.invoke(StandardMBean.java:405)
> at org.apache.activemq.broker.jmx.AnnotatedMBean.invoke(AnnotatedMBean.java:198)
> Strangely, the web admin console is completely responsive and attempting a delete through the web console is highly performant even on large queues.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)