[jira] [Updated] (AMQ-5419) Disconnect between exclusive consumer documentation and functionality
[ https://issues.apache.org/jira/browse/AMQ-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james updated AMQ-5419: --- Attachment: ExclusiveConsumerNetworkTest.java So, i was trying to create a unit test that worked, so i could figure out which scenario worked and which didn't. this was my first attempt at a basic setup, but it doesn't seem to work reliably. occassionally it works, but usually it fails. Any suggestions on how i might be setting this up incorrectly? Disconnect between exclusive consumer documentation and functionality - Key: AMQ-5419 URL: https://issues.apache.org/jira/browse/AMQ-5419 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.9.1 Reporter: james Priority: Critical Attachments: ExclusiveConsumerNetworkTest.java The [exclusive consumer documentation|http://activemq.apache.org/exclusive-consumer.html] seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5419) Disconnect between exclusive consumer documentation and functionality
james created AMQ-5419: -- Summary: Disconnect between exclusive consumer documentation and functionality Key: AMQ-5419 URL: https://issues.apache.org/jira/browse/AMQ-5419 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.9.1 Reporter: james Priority: Critical The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5419) Disconnect between exclusive consumer documentation and functionality
[ https://issues.apache.org/jira/browse/AMQ-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james updated AMQ-5419: --- Description: The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . was: The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem. See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . Disconnect between exclusive consumer documentation and functionality - Key: AMQ-5419 URL: https://issues.apache.org/jira/browse/AMQ-5419 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.9.1 Reporter: james Priority: Critical The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5419) Disconnect between exclusive consumer documentation and functionality
[ https://issues.apache.org/jira/browse/AMQ-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james updated AMQ-5419: --- Description: The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem. See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . was: The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . Disconnect between exclusive consumer documentation and functionality - Key: AMQ-5419 URL: https://issues.apache.org/jira/browse/AMQ-5419 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.9.1 Reporter: james Priority: Critical The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem. See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5419) Disconnect between exclusive consumer documentation and functionality
[ https://issues.apache.org/jira/browse/AMQ-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james updated AMQ-5419: --- Description: The [exclusive consumer documentation|http://activemq.apache.org/exclusive-consumer.html] seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . was: The exclusive consumer documentation seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . Disconnect between exclusive consumer documentation and functionality - Key: AMQ-5419 URL: https://issues.apache.org/jira/browse/AMQ-5419 Project: ActiveMQ Issue Type: Bug Components: Documentation Affects Versions: 5.9.1 Reporter: james Priority: Critical The [exclusive consumer documentation|http://activemq.apache.org/exclusive-consumer.html] seems indicates that this feature is enabled for a given consumer. In practice, however, the feature seems to be tied to the connection as well as the consumer. If a consumer with the exclusive flag enabled is created using a connection without the exclusive flag enabled, the consumer will behave like a normal consumer. The exclusive feature will only work if the connection associated with the consumer also has the exclusive flag enabled. I marked this as a documentation bug, but it's possible that the documentation is the intended behavior and there is actually a code problem? See this thread for more details on my exploration of this feature: http://activemq.2283324.n4.nabble.com/exclusive-consumer-doesn-t-seem-to-be-working-tt4686733.html . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5251) Scheduler missing some synchronization
james created AMQ-5251: -- Summary: Scheduler missing some synchronization Key: AMQ-5251 URL: https://issues.apache.org/jira/browse/AMQ-5251 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.10.0 Reporter: james Priority: Minor the org.apache.activemq.thread.Scheduler.executePeriodically() method should be synchronized since it modifies the timerTasks map. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (AMQ-5161) NullPointerException during async startup
[
https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13994548#comment-13994548
]
james commented on AMQ-5161:
There was actually already a race condition on async startup, as i reported in
the related issue, it just got worse in 5.9.1. i don't think there is
necessarily a need for an isStarted loop. the connector already does something
to that affect _after_ it gets a valid handle to the broker. the gist of the
problem is that there are a few key broker references which _must_ be
initialized before the asynchronous startup part proceeds (i.e. before the
start() method call returns). if you look at the workaround i posted, you can
see which references need to be initialized before the start method returns.
NullPointerException during async startup
-
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
Attachments: QueueService2Test.java
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this
exception on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:759)
at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:145)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
at
org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:247)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5166) MessageDatabase does not consistently apply tracker settings
james created AMQ-5166: -- Summary: MessageDatabase does not consistently apply tracker settings Key: AMQ-5166 URL: https://issues.apache.org/jira/browse/AMQ-5166 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.9.1 Reporter: james Priority: Minor The failoverProducersAuditDepth and maxFailoverProducersToTrack settings for MessageDatabase are actually used by the underlying MetaData's ActiveMQMessageAuditNoSync instance. However, the MetaData instance and ActiveMQMessageAuditNoSync may change over the life of the MessageDatabase, and these settings are not perpetuated to the new instances (or restored instances). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (AMQ-5166) MessageDatabase does not consistently apply tracker settings
[ https://issues.apache.org/jira/browse/AMQ-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james updated AMQ-5166: --- Attachment: aq_patch.txt Attached the aq_patch.txt which ensures that the settings get passed along to every new tracker instance. MessageDatabase does not consistently apply tracker settings Key: AMQ-5166 URL: https://issues.apache.org/jira/browse/AMQ-5166 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 5.9.1 Reporter: james Priority: Minor Attachments: aq_patch.txt The failoverProducersAuditDepth and maxFailoverProducersToTrack settings for MessageDatabase are actually used by the underlying MetaData's ActiveMQMessageAuditNoSync instance. However, the MetaData instance and ActiveMQMessageAuditNoSync may change over the life of the MessageDatabase, and these settings are not perpetuated to the new instances (or restored instances). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (AMQ-5161) NullPointerException during async startup
james created AMQ-5161:
--
Summary: NullPointerException during async startup
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this exception
on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:759)
at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:145)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
at org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:247)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (AMQ-5161) NullPointerException during async startup
[
https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980227#comment-13980227
]
james commented on AMQ-5161:
This is the workaround i have found which seems to get it to work:
{noformat}
BrokerService _broker.setStartAsync(true);
org.apache.activemq.broker.Broker tmpBroker = _broker.getBroker();
org.apache.activemq.broker.Broker tmpRegBroker =
_broker.getRegionBroker();
((org.apache.activemq.broker.jmx.ManagedRegionBroker)tmpRegBroker).setContextBroker(tmpBroker);
_broker.start();
{noformat}
NullPointerException during async startup
-
Key: AMQ-5161
URL: https://issues.apache.org/jira/browse/AMQ-5161
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.1
Reporter: james
I'm using an embedded broker with asynchronous startup enabled. My setup
worked using 5.9.0. When i upgraded to 5.9.1, i started getting this
exception on startup:
{noformat}
javax.jms.JMSException: java.lang.NullPointerException
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
at
org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
at
org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
at ...internal system startup stack trace...
Caused by: java.lang.NullPointerException
at
org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
at
org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:759)
at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:145)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
at
org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:247)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-5118) Race condition with embedded broker asynchronous startup
[
https://issues.apache.org/jira/browse/AMQ-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
james updated AMQ-5118:
---
Attachment: QueueServiceTest.java
It's a race condition, so obviously difficult to test. however, i've
introduced some delays into the broker startup in the test code and they seem
to reliably cause the problem on my box. without the artificial delays, the
test would fail about 1 out of 3 times on my box.
Race condition with embedded broker asynchronous startup
Key: AMQ-5118
URL: https://issues.apache.org/jira/browse/AMQ-5118
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: james
Attachments: QueueServiceTest.java
We run activemq as an embedded broker using the asynchronous startup option.
After the start async call returns, we create a vm connector with the extra
options ?create=falsewaitForStart=6. There is a timing hole where the
BrokerService has been registered with the BrokerRegistry (and is found by
the connection factory), but the BrokerServer.broker member variable has not
yet been assigned (in fact, there may be some memory visibility issues here).
The VMTransportFactory eventually generates a call to
BrokerService.getBroker(), which (since broker == null) attempts to create a
broker instance. This ultimately results in a JMX exception due to multiple
instances being registered (assuming you have jmx enabled).
{noformat}
javax.jms.JMSException: Could not create Transport. Reason:
java.io.IOException: Status MBean could not be registe
red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:260)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246)
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186)
at internal stacktrace ommitted
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Status MBean could not be registered in JMX:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2242)
at
org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2123)
at
org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:906)
at
org.apache.activemq.broker.TransportConnector.start(TransportConnector.java:201)
at
org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:140)
at
org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:54)
at
org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258)
... 37 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:483)
at
org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
at
org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2240)
... 44 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (AMQ-5118) Race condition with embedded broker asynchronous startup
james created AMQ-5118:
--
Summary: Race condition with embedded broker asynchronous startup
Key: AMQ-5118
URL: https://issues.apache.org/jira/browse/AMQ-5118
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: james
We run activemq as an embedded broker using the asynchronous startup option.
We after the start async call returns, we create a vm connector with the extra
options ?create=falsewaitForStart=6. There is a timing hole where the
BrokerService has been registered with the BrokerRegistry (and is found by the
connection factory), but the BrokerServer.broker member variable has not yet
been assigned (in fact, there may be some memory visibility issues here). The
VMTransportFactory eventually generates a call to BrokerService.getBroker(),
which (since broker == null) attempts to create a broker instance. This
ultimately results in a JMX exception due to multiple instances being
registered (assuming you have jmx enabled).
{noformat}
javax.jms.JMSException: Could not create Transport. Reason:
java.io.IOException: Status MBean could not be registe
red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:260)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246)
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186)
at internal stacktrace ommitted
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Status MBean could not be registered in JMX:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2242)
at
org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2123)
at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:906)
at
org.apache.activemq.broker.TransportConnector.start(TransportConnector.java:201)
at
org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:140)
at
org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:54)
at
org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258)
... 37 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:483)
at
org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
at
org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2240)
... 44 more
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (AMQ-5118) Race condition with embedded broker asynchronous startup
[
https://issues.apache.org/jira/browse/AMQ-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
james updated AMQ-5118:
---
Description:
We run activemq as an embedded broker using the asynchronous startup option.
After the start async call returns, we create a vm connector with the extra
options ?create=falsewaitForStart=6. There is a timing hole where the
BrokerService has been registered with the BrokerRegistry (and is found by the
connection factory), but the BrokerServer.broker member variable has not yet
been assigned (in fact, there may be some memory visibility issues here). The
VMTransportFactory eventually generates a call to BrokerService.getBroker(),
which (since broker == null) attempts to create a broker instance. This
ultimately results in a JMX exception due to multiple instances being
registered (assuming you have jmx enabled).
{noformat}
javax.jms.JMSException: Could not create Transport. Reason:
java.io.IOException: Status MBean could not be registe
red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:260)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246)
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186)
at internal stacktrace ommitted
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Status MBean could not be registered in JMX:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2242)
at
org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2123)
at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:906)
at
org.apache.activemq.broker.TransportConnector.start(TransportConnector.java:201)
at
org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:140)
at
org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:54)
at
org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258)
... 37 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:483)
at
org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
at
org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2240)
... 44 more
{noformat}
was:
We run activemq as an embedded broker using the asynchronous startup option.
We after the start async call returns, we create a vm connector with the extra
options ?create=falsewaitForStart=6. There is a timing hole where the
BrokerService has been registered with the BrokerRegistry (and is found by the
connection factory), but the BrokerServer.broker member variable has not yet
been assigned (in fact, there may be some memory visibility issues here). The
VMTransportFactory eventually generates a call to BrokerService.getBroker(),
which (since broker == null) attempts to create a broker instance. This
ultimately results in a JMX exception due to multiple instances being
registered (assuming you have jmx enabled).
{noformat}
javax.jms.JMSException: Could not create Transport. Reason:
java.io.IOException: Status MBean could not be registe
red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
[jira] [Commented] (AMQ-5118) Race condition with embedded broker asynchronous startup
[
https://issues.apache.org/jira/browse/AMQ-5118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13945617#comment-13945617
]
james commented on AMQ-5118:
Note that i've found a workaround for now. If i call BrokerService.getBroker()
before calling BrokerService.start(), the internal broker instance is created
and assigned before the rest of startup proceeds and there is no longer a race
condition with the connection factory startup. During a normal BrokerService
(asynchronous) startup, the Broker instance is not created until after the
persistence adapters are started. I'm not sure what the implications of my
workaround are (creating the broker instance before the persistence adapters
are started) but everything seems to be working fine with this change in place.
Assuming that creating the broker instance earlier in the startup process is
legitimate, maybe the BrokerService could be changed to do that in the start()
method before breaking off for the rest of the asynchronous startup process.
Race condition with embedded broker asynchronous startup
Key: AMQ-5118
URL: https://issues.apache.org/jira/browse/AMQ-5118
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.9.0
Reporter: james
We run activemq as an embedded broker using the asynchronous startup option.
After the start async call returns, we create a vm connector with the extra
options ?create=falsewaitForStart=6. There is a timing hole where the
BrokerService has been registered with the BrokerRegistry (and is found by
the connection factory), but the BrokerServer.broker member variable has not
yet been assigned (in fact, there may be some memory visibility issues here).
The VMTransportFactory eventually generates a call to
BrokerService.getBroker(), which (since broker == null) attempts to create a
broker instance. This ultimately results in a JMX exception due to multiple
instances being registered (assuming you have jmx enabled).
{noformat}
javax.jms.JMSException: Could not create Transport. Reason:
java.io.IOException: Status MBean could not be registe
red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:260)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:273)
at
org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:246)
at
org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:186)
at internal stacktrace ommitted
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Status MBean could not be registered in JMX:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:27)
at
org.apache.activemq.broker.BrokerService.addInterceptors(BrokerService.java:2242)
at
org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:2123)
at
org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:906)
at
org.apache.activemq.broker.TransportConnector.start(TransportConnector.java:201)
at
org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(VMTransportFactory.java:140)
at
org.apache.activemq.transport.vm.VMTransportFactory.doConnect(VMTransportFactory.java:54)
at
org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:64)
at
org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:258)
... 37 more
Caused by: javax.management.InstanceAlreadyExistsException:
org.apache.activemq:type=Broker,brokerName=internal,service=Health
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:483)
at
[jira] [Created] (AMQ-5039) allow for thread pooling with multi kahadb persistence
james created AMQ-5039: -- Summary: allow for thread pooling with multi kahadb persistence Key: AMQ-5039 URL: https://issues.apache.org/jira/browse/AMQ-5039 Project: ActiveMQ Issue Type: Improvement Components: Message Store Affects Versions: 5.9.0 Reporter: james Priority: Minor I am probably using the multi KahaDB storage a bit differently than others, but i expect to be using many instances within my activemq broker. As such, i noticed that the kahadb impl uses a bunch of threads per instance. Some of this may be necessary, but the scheduled tasks at the least could most likely allow for sharing a Timer or ScheduledExecutorService instance. Locations: * Journal creates a Timer instance (even though Scheduler has a shared instance) * MessageDatabase creates a dedicated checkpoint thread (which is essentially a scheduled task) * DataFileAppender has a dedicated writer thread. possibly harder to share. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5017) ActiveMQPrefetchPolicy.setAll sets inputStreamPrefetch incorrectly
james created AMQ-5017: -- Summary: ActiveMQPrefetchPolicy.setAll sets inputStreamPrefetch incorrectly Key: AMQ-5017 URL: https://issues.apache.org/jira/browse/AMQ-5017 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Reporter: james Priority: Minor ActiveMQPrefetchPolicy.setAll() sets this.inputStreamPrefetch to 1, which i assume is supposed to be i. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-5017) ActiveMQPrefetchPolicy.setAll sets inputStreamPrefetch incorrectly
[ https://issues.apache.org/jira/browse/AMQ-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890316#comment-13890316 ] james commented on AMQ-5017: Also i just noticed that setAll() does not use getMaxPrefetch() to limit the new value. dunno if this should be filed as a separate bug. ActiveMQPrefetchPolicy.setAll sets inputStreamPrefetch incorrectly -- Key: AMQ-5017 URL: https://issues.apache.org/jira/browse/AMQ-5017 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.9.0 Reporter: james Priority: Minor ActiveMQPrefetchPolicy.setAll() sets this.inputStreamPrefetch to 1, which i assume is supposed to be i. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13879017#comment-13879017 ] james commented on AMQ-4970: Actually, i may have figured this out myself. topics don't seem to be reloaded at startup like queues. Deletion of a queue inaffective across broker restart - Key: AMQ-4970 URL: https://issues.apache.org/jira/browse/AMQ-4970 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: mac osx/mavericks Reporter: Arthur Naseef Fix For: 5.10.0 Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, amq4970.patch Deleting a queue, it is revived from persistent store after a broker restart. The following steps reproduce the problem: * Create a queue (confirmed using the REST client I/F) * Shutdown the broker * Startup the broker * Confirm queue still exists via the hawtio ui (correct operation so far) * Delete the queue * Confirm queue removed via the hawtio ui * Shutdown the broker * Startup the broker * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQ-4970) Deletion of a queue inaffective across broker restart
[ https://issues.apache.org/jira/browse/AMQ-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877188#comment-13877188 ] james commented on AMQ-4970: Hey Arthur, thanks for tracking this down and figuring out how to fix it. just curious, though, should there be a similar fix applied to Topic.java as well? Deletion of a queue inaffective across broker restart - Key: AMQ-4970 URL: https://issues.apache.org/jira/browse/AMQ-4970 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Environment: mac osx/mavericks Reporter: Arthur Naseef Fix For: 5.10.0 Attachments: AMQ4970Test.zip, AMQ4970Test.zip, AMQ4970Test.zip, amq4970.patch Deleting a queue, it is revived from persistent store after a broker restart. The following steps reproduce the problem: * Create a queue (confirmed using the REST client I/F) * Shutdown the broker * Startup the broker * Confirm queue still exists via the hawtio ui (correct operation so far) * Delete the queue * Confirm queue removed via the hawtio ui * Shutdown the broker * Startup the broker * Confirm queue was not recreated via hawtio ui (failed: queue still exists) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-4902) ineffective use of ThreadPoolExecutor
james created AMQ-4902: -- Summary: ineffective use of ThreadPoolExecutor Key: AMQ-4902 URL: https://issues.apache.org/jira/browse/AMQ-4902 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.9.0 Reporter: james Priority: Minor I noticed that the BrokerService uses a default ThreadPoolExecutor configured with a variable number of threads (1-10) and an unbounded queue (LinkedBlockingQueue). The way that the oracle ThreadPoolExecutor is implemented makes this configuration very ineffective, as it will never use more than 1 thread. The basic strategy in the ThreadPoolExecutor is to add threads until it gets to the core pool size (in this case 1) then prefer queueing. only when an offer to the queue fails will threads be added beyond the core pool size. since the LinkedBlockingQueue is unbounded, offer will never fail and no more threads will be added. There are no great strategies for getting a good variable sized thread pool combined with an unbounded queue using the ThreadPoolExecutor. 2 possible solutions are: * Set min to the max and allow core threads to timeout * using a lying blocking queue which initially rejects offers, but then use a rejected execution handler which puts the elements on the queue. this forces threads to be added up to the max before tasks get queued note that i noticed this in the broker, but i believe this pattern is used in other activemq classes as well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: MasterSlaveBug.java Master/slave out of sync with multiple consumers Key: AMQ-2102 URL: https://issues.apache.org/activemq/browse/AMQ-2102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Dan James Attachments: MasterSlaveBug.java I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Description: I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. Master and slave configurations along with MasterSlaveBug.java are attached to this issue. Start master and slave brokers: activemq xbean:master.xml activemq xbean:slave.xml Run with (only one consumer, the bug does not appear): java -classpath .:activemq-all-5.2.0.jar MasterSlaveBug 1 Run with (sixteen consumers, the bug does appear): java -classpath .:activemq-all-5.2.0.jar MasterSlaveBug 16 was: I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. Master/slave out of sync with multiple consumers Key: AMQ-2102 URL: https://issues.apache.org/activemq/browse/AMQ-2102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Dan James Attachments: master.xml, MasterSlaveBug.java, slave.xml I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException:
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: slave.xml Master/slave out of sync with multiple consumers Key: AMQ-2102 URL: https://issues.apache.org/activemq/browse/AMQ-2102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Dan James Attachments: master.xml, MasterSlaveBug.java, slave.xml I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2102) Master/slave out of sync with multiple consumers
[ https://issues.apache.org/activemq/browse/AMQ-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan James updated AMQ-2102: --- Attachment: master.xml Master/slave out of sync with multiple consumers Key: AMQ-2102 URL: https://issues.apache.org/activemq/browse/AMQ-2102 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Dan James Attachments: master.xml, MasterSlaveBug.java, slave.xml I'm seeing exceptions like this in a simple master/slave setup: ERROR Service- Async error occurred: javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug javax.jms.JMSException: Slave broker out of sync with master: Dispatched message (ID:DUL1SJAMES-L2-1231-1233929569359-0:4:1:1:207) was not in the pending list for MasterSlaveBug The problem only happens when there are multiple consumers listening to the queue, and is more likely to occur as there are more consumers listening. I've written a test program that demonstrates the problem. I start the master and slave with an empty data directory and let them both startup and settle. Then start the test program. The test program creates a specified number of consumers, and then starts queuing 256 messages. The consumers process the message by sending a reply. The producer counts the replies. Both consumers and the producer see all the messages, but with multiple consumers it is very likely that the error above will occur and several of the messages will still be queued on the slave. While debugging through the activemq code, I noticed that both the master and the slave dispatch the message to a consumer's pending list independently. In other words, it is possible that the master will add the message to consumer A's pending list and the slave will add the message to consumer B's pending list. Once the message has been processed by consumer A, the master sends a message to the slaving which specifies consumer A so that the slave can remove the message. The slave looks on its copy of consumer A's pending list and cannot find the message. As a result, it throws this exception and the message stays stuck on consumer B's pending list on the slave. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
