ActiveMQ
  1. ActiveMQ
  2. AMQ-2439

KahaDB + Network of Brokers + Restart = Duplicate Messages that cannot be removed from the data store

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.3.1, 5.4.0
    • Component/s: Broker, Message Store
    • Labels:
      None
    • Regression:
      Regression

      Description

      Every time the broker is restarted, the same set of duplicate messages get redelivered to consumers.

      1. amq2439-patch.diff
        12 kB
        Gary Tully
      2. AMQ-2439patch.txt
        32 kB
        Colin MacNaughton

        Activity

        Hide
        Hiram Chirino added a comment -

        How to reproduce:
        Start broker 1 with config:

        <beans
          xmlns="http://www.springframework.org/schema/beans"
          xmlns:amq="http://activemq.apache.org/schema/core"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
          http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">
        
            <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
                <property name="locations">
                    <value>file:${activemq.base}/conf/credentials.properties</value>
                </property>
            </bean>
        
            <broker xmlns="http://activemq.apache.org/schema/core"  brokerName="activemq1" dataDirectory="${activemq.base}/data">
                <networkConnectors>
                        <networkConnector
                                uri="static://(tcp://localhost:61617)"
                                name="Connection to 61617"
                                dynamicOnly="true"/>
        
                </networkConnectors>
                <persistenceAdapter>
                        <kahaDB directory="${activemq.base}/data/kaha" journalMaxFileLength="32mb"/>
                </persistenceAdapter>
                <systemUsage>
                  <systemUsage>
                    <memoryUsage>
                      <memoryUsage limit="50 mb" />
                    </memoryUsage>
                    <storeUsage>
                      <storeUsage limit="4 gb" />
                    </storeUsage>
                    <tempUsage>
                      <tempUsage limit="200 mb" />
                    </tempUsage>
                  </systemUsage>
                </systemUsage>
                <transportConnectors>
                    <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
                </transportConnectors>
        
            </broker>
                <jetty xmlns="http://mortbay.com/schemas/jetty/1.0">
                <connectors>
                    <nioConnector port="8161"/>
                </connectors>
        
                <handlers>
                    <webAppContext contextPath="/admin" resourceBase="${activemq.base}/webapps/admin" logUrlOnStart="true"/>
                </handlers>
            </jetty>
        
        </beans>
        

        and broker 2 with config:

        <beans
          xmlns="http://www.springframework.org/schema/beans"
          xmlns:amq="http://activemq.apache.org/schema/core"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
          http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">
        
            <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
                <property name="locations">
                    <value>file:${activemq.base}/conf/credentials.properties</value>
                </property>
            </bean>
        
            <broker xmlns="http://activemq.apache.org/schema/core"  brokerName="activemq2" dataDirectory="${activemq.base}/data">
                <networkConnectors>
                        <networkConnector
                                uri="static://(tcp://localhost:61616)"
                                name="Connection to 61616"
                                dynamicOnly="true"/>
        
                </networkConnectors>
                <persistenceAdapter>
                        <kahaDB directory="${activemq.base}/data/kaha" journalMaxFileLength="32mb"/>
                </persistenceAdapter>
                <systemUsage>
                  <systemUsage>
                    <memoryUsage>
                      <memoryUsage limit="50 mb" />
                    </memoryUsage>
                    <storeUsage>
                      <storeUsage limit="4 gb" />
                    </storeUsage>
                    <tempUsage>
                      <tempUsage limit="200 mb" />
                    </tempUsage>
                  </systemUsage>
                </systemUsage>
                <transportConnectors>
                    <transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>
                </transportConnectors>
        
            </broker>
                <jetty xmlns="http://mortbay.com/schemas/jetty/1.0">
                <connectors>
                    <nioConnector port="8162"/>
                </connectors>
        
                <handlers>
                    <webAppContext contextPath="/admin" resourceBase="${activemq.base}/webapps/admin" logUrlOnStart="true"/>
                </handlers>
            </jetty>
        
        </beans>
        

        Use the example producer and consumer in the distribution examples dir:

        ant producer -Durl=tcp://localhost:61616  -Dtopic=false -Ddurable=true -Dmax=1000
        
        ant consumer -Durl=tcp://localhost:61617 -Dtopic=false -Ddurable=true -Dmax=500
        

        run the producer once.
        run that consumer 2 times.
        then restart the broker on port 61617
        and run the consumer again.

        The 3rd run of the consumer should get no messages but it receives multiple messages. What's worse is that restarting the broker and consumer will result in the same duplicates getting delivered again.

        Show
        Hiram Chirino added a comment - How to reproduce: Start broker 1 with config: <beans xmlns= "http://www.springframework.org/schema/beans" xmlns:amq = "http://activemq.apache.org/schema/core" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd"> <bean class= "org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" > <property name= "locations" > <value> file:${activemq.base}/conf/credentials.properties </value> </property> </bean> <broker xmlns= "http://activemq.apache.org/schema/core" brokerName= "activemq1" dataDirectory= "${activemq.base}/data" > <networkConnectors> <networkConnector uri= "static://(tcp://localhost:61617)" name= "Connection to 61617" dynamicOnly= "true" /> </networkConnectors> <persistenceAdapter> <kahaDB directory= "${activemq.base}/data/kaha" journalMaxFileLength= "32mb" /> </persistenceAdapter> <systemUsage> <systemUsage> <memoryUsage> <memoryUsage limit= "50 mb" /> </memoryUsage> <storeUsage> <storeUsage limit= "4 gb" /> </storeUsage> <tempUsage> <tempUsage limit= "200 mb" /> </tempUsage> </systemUsage> </systemUsage> <transportConnectors> <transportConnector name= "openwire" uri= "tcp://0.0.0.0:61616" /> </transportConnectors> </broker> <jetty xmlns= "http://mortbay.com/schemas/jetty/1.0" > <connectors> <nioConnector port= "8161" /> </connectors> <handlers> <webAppContext contextPath= "/admin" resourceBase= "${activemq.base}/webapps/admin" logUrlOnStart= "true" /> </handlers> </jetty> </beans> and broker 2 with config: <beans xmlns= "http://www.springframework.org/schema/beans" xmlns:amq = "http://activemq.apache.org/schema/core" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd"> <bean class= "org.springframework.beans.factory.config.PropertyPlaceholderConfigurer" > <property name= "locations" > <value> file:${activemq.base}/conf/credentials.properties </value> </property> </bean> <broker xmlns= "http://activemq.apache.org/schema/core" brokerName= "activemq2" dataDirectory= "${activemq.base}/data" > <networkConnectors> <networkConnector uri= "static://(tcp://localhost:61616)" name= "Connection to 61616" dynamicOnly= "true" /> </networkConnectors> <persistenceAdapter> <kahaDB directory= "${activemq.base}/data/kaha" journalMaxFileLength= "32mb" /> </persistenceAdapter> <systemUsage> <systemUsage> <memoryUsage> <memoryUsage limit= "50 mb" /> </memoryUsage> <storeUsage> <storeUsage limit= "4 gb" /> </storeUsage> <tempUsage> <tempUsage limit= "200 mb" /> </tempUsage> </systemUsage> </systemUsage> <transportConnectors> <transportConnector name= "openwire" uri= "tcp://0.0.0.0:61617" /> </transportConnectors> </broker> <jetty xmlns= "http://mortbay.com/schemas/jetty/1.0" > <connectors> <nioConnector port= "8162" /> </connectors> <handlers> <webAppContext contextPath= "/admin" resourceBase= "${activemq.base}/webapps/admin" logUrlOnStart= "true" /> </handlers> </jetty> </beans> Use the example producer and consumer in the distribution examples dir: ant producer -Durl=tcp: //localhost:61616 -Dtopic= false -Ddurable= true -Dmax=1000 ant consumer -Durl=tcp: //localhost:61617 -Dtopic= false -Ddurable= true -Dmax=500 run the producer once. run that consumer 2 times. then restart the broker on port 61617 and run the consumer again. The 3rd run of the consumer should get no messages but it receives multiple messages. What's worse is that restarting the broker and consumer will result in the same duplicates getting delivered again.
        Hide
        Hiram Chirino added a comment -

        I confirmed that KahaDB indexes were inconsistent on a restart and that is the reason the same duplicate message kept getting re-delivered.
        I seems the reason the indexes were becoming inconsistent is because it was not being defensive when it add new messages. If a duplicate message was added to kahadb it's two of it's btrees would no longer be consistent.

        Show
        Hiram Chirino added a comment - I confirmed that KahaDB indexes were inconsistent on a restart and that is the reason the same duplicate message kept getting re-delivered. I seems the reason the indexes were becoming inconsistent is because it was not being defensive when it add new messages. If a duplicate message was added to kahadb it's two of it's btrees would no longer be consistent.
        Hide
        Hiram Chirino added a comment -

        I will work on message store unit test to see if there are any other store which also are not being defensive about dup messages.

        We still need to work out why the broker is tryping to store a dup message in the first place.

        Show
        Hiram Chirino added a comment - I will work on message store unit test to see if there are any other store which also are not being defensive about dup messages. We still need to work out why the broker is tryping to store a dup message in the first place.
        Hide
        Hiram Chirino added a comment -

        Rob want to take a crack at figuring out whats causing the dup on the network?

        Show
        Hiram Chirino added a comment - Rob want to take a crack at figuring out whats causing the dup on the network?
        Hide
        Gary Tully added a comment -

        the dups are coming from ignored acks from the network bridge.
        The network consumer with default prefetch is happy to take all of the messages and they are dispatched async. During the dispatch, the remove consumer is happy with its 500 messages and closes. The close propagates back to the network consumer but between the consumer remove operation and the disposing of the bridge a few messages are dispatched but cannot be acked.

        Some logic in: org.apache.activemq.broker.region.AbstractRegion.acknowledge(ConsumerBrokerExchange, MessageAck) is happy to silently ignore the ack and the result is a resend.

        The remove signal should terminate dispatch and await any outstanding ack but not hang forever. need to investigate a bit more to see if there is a solution.

        Show
        Gary Tully added a comment - the dups are coming from ignored acks from the network bridge. The network consumer with default prefetch is happy to take all of the messages and they are dispatched async. During the dispatch, the remove consumer is happy with its 500 messages and closes. The close propagates back to the network consumer but between the consumer remove operation and the disposing of the bridge a few messages are dispatched but cannot be acked. Some logic in: org.apache.activemq.broker.region.AbstractRegion.acknowledge(ConsumerBrokerExchange, MessageAck) is happy to silently ignore the ack and the result is a resend. The remove signal should terminate dispatch and await any outstanding ack but not hang forever. need to investigate a bit more to see if there is a solution.
        Hide
        Gary Tully added a comment -

        patch that resolves the duplicate issue, worth a quick review (as I am just doing a test run atm) of the org.apache.activemq.network.DemandSubscription.waitForCompletion() implementation.
        I pulled the existing logic for dealing with acks for no subscriptions in AbstractRegion that was the root cause. With the changes, any acks that don't have a sub should be considered an error and result in an exception.
        will commit pending no issues showing up in my local test run.

        Show
        Gary Tully added a comment - patch that resolves the duplicate issue, worth a quick review (as I am just doing a test run atm) of the org.apache.activemq.network.DemandSubscription.waitForCompletion() implementation. I pulled the existing logic for dealing with acks for no subscriptions in AbstractRegion that was the root cause. With the changes, any acks that don't have a sub should be considered an error and result in an exception. will commit pending no issues showing up in my local test run.
        Hide
        Gary Tully added a comment -

        resolved in r822811

        async dispatch of messages by the bridge was resulting in acks to removed subs as the response to a remove advisory did not know about outstanding requests, the sub now waits till outstanding delivered messages have been acked such that it will not deliver duplicates.

        Show
        Gary Tully added a comment - resolved in r822811 async dispatch of messages by the bridge was resulting in acks to removed subs as the response to a remove advisory did not know about outstanding requests, the sub now waits till outstanding delivered messages have been acked such that it will not deliver duplicates.
        Hide
        Hiram Chirino added a comment -

        applied my kahadb changes to the 5.3 branch.

        Show
        Hiram Chirino added a comment - applied my kahadb changes to the 5.3 branch.
        Hide
        Gary Tully added a comment -

        dito. merged duplicate message fix to 5.3 branch: r822811

        Show
        Gary Tully added a comment - dito. merged duplicate message fix to 5.3 branch: r822811
        Hide
        Colin MacNaughton added a comment -

        Seeing the exception below in a 2 broker cluster with this fix which is causing the cluster network connection to be dropped. When an MessageDispatch that was sent async is sent through the bridge, it is sent oneway over the transport and then acked back to the local broker in the sending thread. The problem is that peer broker might concurrently be closing the subscription during the send, and the resulting ack now generates an IllegalStateException when the subscription isn't found. To fix, I'm adding tighter synchronization around subscription tear down to avoid this case. (See attached patch)

        22:19:55 [REMOTE] BROKER1: 22:19:55 WARN  AbstractRegion: Ack for non existent subscription, ack:MessageAck {commandId = 8392, responseRequired = false, ackType = 4, 
        consumerId = ID:nbcmacnaug1-3881-1257920362625-5:1:1:6, firstMessageId = null, lastMessageId = ID:nbcmacnaug1-3919-1257920382750-1:14:1:1:1236, 
        destination = queue://QUEUE-Profile-6, transactionId = null, messageCount = 1} 
        22:19:55 [REMOTE] BROKER1: 22:19:55 WARN  Service: Async error occurred: java.lang.IllegalArgumentException: The subscription does not exist: ID:nbcmacnaug1-3881-1257920362625-5:1:1:6 
        22:19:55 [REMOTE] BROKER1: java.lang.IllegalArgumentException: The subscription does not exist: ID:nbcmacnaug1-3881-1257920362625-5:1:1:6 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:363) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:85) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:449) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.command.MessageAck.visit(MessageAck.java:205) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:297) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:175) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:112) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceLocalCommand(DemandForwardingBridgeSupport.java:708) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.network.DemandForwardingBridgeSupport$1.onCommand(DemandForwardingBridgeSupport.java:159) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:112) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1190) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:779) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:815) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122) 
        22:19:55 [REMOTE] BROKER1: 	at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) 
        22:19:55 [REMOTE] BROKER1: 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) 
        22:19:55 [REMOTE] BROKER1: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) 
        22:19:55 [REMOTE] BROKER1: 	at java.lang.Thread.run(Thread.java:595) 
        
        Show
        Colin MacNaughton added a comment - Seeing the exception below in a 2 broker cluster with this fix which is causing the cluster network connection to be dropped. When an MessageDispatch that was sent async is sent through the bridge, it is sent oneway over the transport and then acked back to the local broker in the sending thread. The problem is that peer broker might concurrently be closing the subscription during the send, and the resulting ack now generates an IllegalStateException when the subscription isn't found. To fix, I'm adding tighter synchronization around subscription tear down to avoid this case. (See attached patch) 22:19:55 [REMOTE] BROKER1: 22:19:55 WARN AbstractRegion: Ack for non existent subscription, ack:MessageAck {commandId = 8392, responseRequired = false , ackType = 4, consumerId = ID:nbcmacnaug1-3881-1257920362625-5:1:1:6, firstMessageId = null , lastMessageId = ID:nbcmacnaug1-3919-1257920382750-1:14:1:1:1236, destination = queue: //QUEUE-Profile-6, transactionId = null , messageCount = 1} 22:19:55 [REMOTE] BROKER1: 22:19:55 WARN Service: Async error occurred: java.lang.IllegalArgumentException: The subscription does not exist: ID:nbcmacnaug1-3881-1257920362625-5:1:1:6 22:19:55 [REMOTE] BROKER1: java.lang.IllegalArgumentException: The subscription does not exist: ID:nbcmacnaug1-3881-1257920362625-5:1:1:6 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:363) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:74) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:85) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:449) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.command.MessageAck.visit(MessageAck.java:205) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:297) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:175) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:112) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceLocalCommand(DemandForwardingBridgeSupport.java:708) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.network.DemandForwardingBridgeSupport$1.onCommand(DemandForwardingBridgeSupport.java:159) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:109) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:112) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1190) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:779) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:815) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122) 22:19:55 [REMOTE] BROKER1: at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43) 22:19:55 [REMOTE] BROKER1: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) 22:19:55 [REMOTE] BROKER1: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) 22:19:55 [REMOTE] BROKER1: at java.lang. Thread .run( Thread .java:595)
        Hide
        Colin MacNaughton added a comment - - edited

        Patch for IllegalState Issue (against revision 835714)

        Show
        Colin MacNaughton added a comment - - edited Patch for IllegalState Issue (against revision 835714)
        Hide
        Colin MacNaughton added a comment -

        Fixed IllegalStateException issue in revision 835715.

        Show
        Colin MacNaughton added a comment - Fixed IllegalStateException issue in revision 835715.
        Hide
        Colin MacNaughton added a comment -

        Changing fix to 5.3.1/5.4.0

        Show
        Colin MacNaughton added a comment - Changing fix to 5.3.1/5.4.0
        Hide
        Gary Tully added a comment -

        nice catch, looks good. that is the final bit of the puzzle.

        Show
        Gary Tully added a comment - nice catch, looks good. that is the final bit of the puzzle.

          People

          • Assignee:
            Colin MacNaughton
            Reporter:
            Hiram Chirino
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development