[jira] [Commented] (AMQ-5896) Problem getting jmx queue when another is deleting during request
[
https://issues.apache.org/jira/browse/AMQ-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650057#comment-14650057
]
ASF subversion and git services commented on AMQ-5896:
--
Commit b64b8ba27e876a011f62f70ffdfc6e7cde1fff24 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b64b8ba ]
https://issues.apache.org/jira/browse/AMQ-5896
Removing the dependency on the ExceptionUtils class in Apache Commons
as that dependency is only available at test time
Problem getting jmx queue when another is deleting during request
-
Key: AMQ-5896
URL: https://issues.apache.org/jira/browse/AMQ-5896
Project: ActiveMQ
Issue Type: Bug
Reporter: Wouter de Vaal
Assignee: Christopher L. Shannon
Fix For: 5.12.0
When calling RemoteJMXBrokerFacade to get information on a queue, but while
doing this another queue can be removed, leaving the method to throw an
exception:
{noformat}
Caused by: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy228.getName(Unknown Source)
at
org.apache.activemq.web.BrokerFacadeSupport.getDestinationByName(BrokerFacadeSupport.java:131)
at
org.apache.activemq.web.BrokerFacadeSupport.getQueue(BrokerFacadeSupport.java:118)
... 3 more
Caused by: javax.management.InstanceNotFoundException:
org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=20150720083000_82a7f1c6-2eb9-11e5-9d34-0242ac110091
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
at
javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$2.run(Transport.java:202)
at sun.rmi.transport.Transport$2.run(Transport.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:906)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:267)
... 7 more
{noformat}
So what happens is that method getDestinationByName first gets a list of all
the queue names. Then it iterates through them when meanwhile a queue gets
deleted and thus throwing an exception. Fix should probably be in
BrokerFacadeSupport:
{noformat}
protected DestinationViewMBean
[jira] [Created] (AMQ-5911) Add loopback test that allows correlation to determine lost mesages
Jakub Korab created AMQ-5911: Summary: Add loopback test that allows correlation to determine lost mesages Key: AMQ-5911 URL: https://issues.apache.org/jira/browse/AMQ-5911 Project: ActiveMQ Issue Type: New Feature Components: Performance Test Affects Versions: 5.11.1 Reporter: Jakub Korab At the moment to determine whether some behaviour on the broker side causes message loss, you need to start a producer and consumer with equal message counts as terminating conditions, and cross-check their reports. This is a fairly crude method. It would be useful to have a single command line loopback test that starts a producer and consumer against the same or different brokers, that correlates messages sent and received, and reports any message loss at the end. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5857) Message content stored twice while sending
[ https://issues.apache.org/jira/browse/AMQ-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649642#comment-14649642 ] ASF subversion and git services commented on AMQ-5857: -- Commit 310c2bb05916811a25b84d76f11fb84b40087914 in activemq's branch refs/heads/master from [~cshannon] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=310c2bb ] https://issues.apache.org/jira/browse/AMQ-5857 Fixing a potential race condition in the storeContent method of ActiveMQTextMessage Message content stored twice while sending -- Key: AMQ-5857 URL: https://issues.apache.org/jira/browse/AMQ-5857 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.10.0, 5.11.0 Reporter: Benjamin Graf Assignee: Christopher L. Shannon Fix For: 5.12.0 The storeContent method in ActiveMQTextMessage does not clean text field after storing content. Therefor the message temporary exists twice which can lead to OOM problems for large or many text messages concurrently processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMQ-5857) Message content stored twice while sending
[ https://issues.apache.org/jira/browse/AMQ-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon reopened AMQ-5857: - Regression: Unit Test Broken This fix has caused a test to fail: org.apache.activemq.camel.CamelVMTransportRoutingTest.testSendReceiveWithCamelRouteIntercepting There appears to be a race condition. Message content stored twice while sending -- Key: AMQ-5857 URL: https://issues.apache.org/jira/browse/AMQ-5857 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.10.0, 5.11.0 Reporter: Benjamin Graf Assignee: Christopher L. Shannon Fix For: 5.12.0 The storeContent method in ActiveMQTextMessage does not clean text field after storing content. Therefor the message temporary exists twice which can lead to OOM problems for large or many text messages concurrently processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5857) Message content stored twice while sending
[ https://issues.apache.org/jira/browse/AMQ-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-5857. - Resolution: Fixed Regression: (was: Unit Test Broken) There was a race condition in the storeContext() method of ActiveMQTextMessage where in between checking the text field for null and writing the content of text to the stream, the text field was set to null. A fix has been applied that caches the reference to the text string locally in the method to prevent having to synchronize. I also tweaked a couple other methods with a similar change to prevent the same issue. CamelVmTransportRoutingTest is now passing again. I will double check with Jenkins tomorrow to make sure the test failure has been cleared up. Message content stored twice while sending -- Key: AMQ-5857 URL: https://issues.apache.org/jira/browse/AMQ-5857 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0, 5.8.0, 5.9.0, 5.10.0, 5.11.0 Reporter: Benjamin Graf Assignee: Christopher L. Shannon Fix For: 5.12.0 The storeContent method in ActiveMQTextMessage does not clean text field after storing content. Therefor the message temporary exists twice which can lead to OOM problems for large or many text messages concurrently processing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-162) Can't create colocated HA topology with JGroups discovery
[
https://issues.apache.org/jira/browse/ARTEMIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-162:
--
Assignee: Justin Bertram
Can't create colocated HA topology with JGroups discovery
-
Key: ARTEMIS-162
URL: https://issues.apache.org/jira/browse/ARTEMIS-162
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Assignee: Justin Bertram
Priority: Critical
Fix For: 1.0.1
Hi, I tried to start two Artemis nodes from our application server in
colocated topology with JGroups as discovery method, but i'm not able to do
it. After both nodes are up, this exception starts spamming in logs:
{noformat}
java.io.NotSerializableException: org.jgroups.JChannel
10:56:50,187 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.util.ArrayList.writeObject(ArrayList.java:747)
10:56:50,189 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.lang.reflect.Method.invoke(Method.java:483)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,192 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy(ConfigurationImpl.java:1528)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateReplicatedBackup(ColocatedHAManager.java:190)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateBackup(ColocatedHAManager.java:104)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.impl.ColocatedActivation$1.handlePacket(ColocatedActivation.java:141)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ClusterController$ClusterControllerChannelHandler.handlePacket(ClusterController.java:424)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:652)
10:56:50,193 ERROR [stderr] (default I/O-5) at
[jira] [Commented] (ARTEMIS-162) Can't create colocated HA topology with JGroups discovery
[
https://issues.apache.org/jira/browse/ARTEMIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649741#comment-14649741
]
Justin Bertram commented on ARTEMIS-162:
[~jmesnil], can you attach your configuration files, please?
Can't create colocated HA topology with JGroups discovery
-
Key: ARTEMIS-162
URL: https://issues.apache.org/jira/browse/ARTEMIS-162
Project: ActiveMQ Artemis
Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Jeff Mesnil
Priority: Critical
Fix For: 1.0.1
Hi, I tried to start two Artemis nodes from our application server in
colocated topology with JGroups as discovery method, but i'm not able to do
it. After both nodes are up, this exception starts spamming in logs:
{noformat}
java.io.NotSerializableException: org.jgroups.JChannel
10:56:50,187 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,188 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,189 ERROR [stderr] (default I/O-5) at
java.util.ArrayList.writeObject(ArrayList.java:747)
10:56:50,189 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
10:56:50,190 ERROR [stderr] (default I/O-5) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.lang.reflect.Method.invoke(Method.java:483)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
10:56:50,190 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
10:56:50,191 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
10:56:50,192 ERROR [stderr] (default I/O-5) at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.copy(ConfigurationImpl.java:1528)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateReplicatedBackup(ColocatedHAManager.java:190)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ha.ColocatedHAManager.activateBackup(ColocatedHAManager.java:104)
10:56:50,192 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.impl.ColocatedActivation$1.handlePacket(ColocatedActivation.java:141)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.server.cluster.ClusterController$ClusterControllerChannelHandler.handlePacket(ClusterController.java:424)
10:56:50,193 ERROR [stderr] (default I/O-5) at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:652)
10:56:50,193 ERROR [stderr] (default I/O-5) at
[jira] [Created] (AMQ-5909) Perf test send/receive by count does not complete on Windows
Jakub Korab created AMQ-5909: Summary: Perf test send/receive by count does not complete on Windows Key: AMQ-5909 URL: https://issues.apache.org/jira/browse/AMQ-5909 Project: ActiveMQ Issue Type: Bug Components: Performance Test Affects Versions: 5.11.1 Environment: Windows 7 Reporter: Jakub Korab The performance test tool does not complete when producer.sendType=count or consumer.recvType=count on Windows. A thread dump shows that a thread suspended on AbstractJmsClientSystem.runSystemTest() line 142: samplerCompletionLatch.await(). The same command line on a Linux machine runs the performance test as expected. Command line: mvn activemq-perf:consumer -Dfactory.brokerURL=failover:(tcp://localhost:61616) -Dconsumer.destName=queue://loadtestPL -DsessAckMode=clientAck -DsysTest.clientPrefix=TestPLC -Dfactory.prefetchQueue=10 -Dconsumer.recvCount=8000 -Dconsumer.recvType=count -Dconsumer.recvDelay=50 -Dconsumer.asyncRecv=false -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5896) Problem getting jmx queue when another is deleting during request
[
https://issues.apache.org/jira/browse/AMQ-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649124#comment-14649124
]
ASF subversion and git services commented on AMQ-5896:
--
Commit ac3d088647cacfe298a61ba5b9f1b3941249142d in activemq's branch
refs/heads/master from [~christopher.l.shannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ac3d088 ]
https://issues.apache.org/jira/browse/AMQ-5896
Fixing a potential race condition with BrokerFacacdeSupport that could
cause an InstanceNotFoundException when getting a destination from
a RemoteJMXBrokerFacade instance
Problem getting jmx queue when another is deleting during request
-
Key: AMQ-5896
URL: https://issues.apache.org/jira/browse/AMQ-5896
Project: ActiveMQ
Issue Type: Bug
Reporter: Wouter de Vaal
Assignee: Christopher L. Shannon
Fix For: 5.12.0
When calling RemoteJMXBrokerFacade to get information on a queue, but while
doing this another queue can be removed, leaving the method to throw an
exception:
{noformat}
Caused by: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy228.getName(Unknown Source)
at
org.apache.activemq.web.BrokerFacadeSupport.getDestinationByName(BrokerFacadeSupport.java:131)
at
org.apache.activemq.web.BrokerFacadeSupport.getQueue(BrokerFacadeSupport.java:118)
... 3 more
Caused by: javax.management.InstanceNotFoundException:
org.apache.activemq:type=Broker,brokerName=localhost,destinationType=Queue,destinationName=20150720083000_82a7f1c6-2eb9-11e5-9d34-0242ac110091
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:643)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
at
javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$2.run(Transport.java:202)
at sun.rmi.transport.Transport$2.run(Transport.java:199)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at
javax.management.remote.rmi.RMIConnectionImpl_Stub.getAttribute(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.getAttribute(RMIConnector.java:906)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:267)
... 7 more
{noformat}
So what happens is that method getDestinationByName first gets a list of all
the queue names. Then it iterates through them when meanwhile a queue gets
deleted and thus throwing an exception. Fix should probably be in
BrokerFacadeSupport:
[jira] [Created] (AMQ-5910) When sending/receiving by count, the final reports show incorrect counts
Jakub Korab created AMQ-5910: Summary: When sending/receiving by count, the final reports show incorrect counts Key: AMQ-5910 URL: https://issues.apache.org/jira/browse/AMQ-5910 Project: ActiveMQ Issue Type: Bug Components: Performance Test Affects Versions: 5.11.1 Reporter: Jakub Korab When sending or receiving messages by count, the code runs in a loop against a counter and completes once the count is reached. The reports printed out at the end frequently show a number that is less by up to ~30 messages when count=3. The JMX statistics of the broker confirm that the number of messages specified on the command line were consumed or sent, so this appears to have something to do with the reporting part. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5908) Receive delay not applied on async receive by count
[ https://issues.apache.org/jira/browse/AMQ-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649102#comment-14649102 ] Jakub Korab commented on AMQ-5908: -- Pull request coming in soon. Receive delay not applied on async receive by count --- Key: AMQ-5908 URL: https://issues.apache.org/jira/browse/AMQ-5908 Project: ActiveMQ Issue Type: Bug Components: Performance Test Affects Versions: 5.11.1 Reporter: Jakub Korab Priority: Minor The -Dconsumer.recvDelay flag has no effect when -Dconsumer.recvType=async (the default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5908) Receive delay not applied on async receive by count
Jakub Korab created AMQ-5908: Summary: Receive delay not applied on async receive by count Key: AMQ-5908 URL: https://issues.apache.org/jira/browse/AMQ-5908 Project: ActiveMQ Issue Type: Bug Components: Performance Test Affects Versions: 5.11.1 Reporter: Jakub Korab Priority: Minor The -Dconsumer.recvDelay flag has no effect when -Dconsumer.recvType=async (the default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
