[jira] Created: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
Problem with subscription passing with network of brokers in AMQ 4.0.2
----------------------------------------------------------------------

                 Key: AMQ-961
                 URL: https://issues.apache.org/activemq/browse/AMQ-961
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 4.0.2
            Reporter: Kevin Yaussy
            Priority: Critical


There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.

1) Start broker A (has a network connection to broker B)
2) Start broker B (has a network connection to broker A)
3) start consumer C against broker A, on FOO
4) start publisher P against broker B, on FOO

Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.

I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.

Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
"ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
e2ff000..0x8e2ff8f0]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
        at java.lang.Object.wait(Object.java:474)
        at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
        - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
        at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
.java:830)
        at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
geSupport.java:329)
        at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
.java:130)
        at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
        at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
        at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
        at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
        at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
        at java.lang.Thread.run(Thread.java:595)


Stack trace of broker A when everything works correctly:

"ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:129)
        at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
        at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
        at java.io.DataInputStream.readInt(DataInputStream.java:353)
        at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
        at java.lang.Thread.run(Thread.java:595)



--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
     [ https://issues.apache.org/activemq/browse/AMQ-961?page=all ]

Holger Bruch updated AMQ-961:
-----------------------------

    Attachment: RestartDFBOnResume.diff

Might relate to the problem I encountered in http://www.nabble.com/Failover-and-DemandForwardingBridge-tf2383410.html#a6642973.
Apparently, the DemandForwardingBridge does not resume correctly after a network interruption.
For me, the attached patch worked, but I'm not aware of any side effects, so please check.

> Problem with subscription passing with network of brokers in AMQ 4.0.2
> ----------------------------------------------------------------------
>
>                 Key: AMQ-961
>                 URL: https://issues.apache.org/activemq/browse/AMQ-961
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: Kevin Yaussy
>            Priority: Critical
>         Attachments: RestartDFBOnResume.diff
>
>
> There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.
> 1) Start broker A (has a network connection to broker B)
> 2) Start broker B (has a network connection to broker A)
> 3) start consumer C against broker A, on FOO
> 4) start publisher P against broker B, on FOO
> Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.
> I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.
> Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
> e2ff000..0x8e2ff8f0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at java.lang.Object.wait(Object.java:474)
>         at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
>         - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
> .java:830)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
> geSupport.java:329)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
> .java:130)
>         at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
>         at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>         at java.lang.Thread.run(Thread.java:595)
> Stack trace of broker A when everything works correctly:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
>         at java.io.DataInputStream.readInt(DataInputStream.java:353)
>         at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
>         at java.lang.Thread.run(Thread.java:595)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org
    [ https://issues.apache.org/activemq/browse/AMQ-961?page=comments#action_37133 ]
           
Kevin Yaussy commented on AMQ-961:
----------------------------------

Thanks.  I will apply this patch and try it out.


> Problem with subscription passing with network of brokers in AMQ 4.0.2
> ----------------------------------------------------------------------
>
>                 Key: AMQ-961
>                 URL: https://issues.apache.org/activemq/browse/AMQ-961
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: Kevin Yaussy
>            Priority: Critical
>         Attachments: RestartDFBOnResume.diff
>
>
> There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.
> 1) Start broker A (has a network connection to broker B)
> 2) Start broker B (has a network connection to broker A)
> 3) start consumer C against broker A, on FOO
> 4) start publisher P against broker B, on FOO
> Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.
> I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.
> Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
> e2ff000..0x8e2ff8f0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at java.lang.Object.wait(Object.java:474)
>         at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
>         - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
> .java:830)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
> geSupport.java:329)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
> .java:130)
>         at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
>         at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>         at java.lang.Thread.run(Thread.java:595)
> Stack trace of broker A when everything works correctly:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
>         at java.io.DataInputStream.readInt(DataInputStream.java:353)
>         at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
>         at java.lang.Thread.run(Thread.java:595)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org
    [ https://issues.apache.org/activemq/browse/AMQ-961?page=comments#action_37134 ]
           
Kevin Yaussy commented on AMQ-961:
----------------------------------

This does appear to fix the problem.  I'd had a similar problem with AMQ 4.0.1, reported in AMQ-776, which I had fixed.  But, for the second part of that problem, the original patch did not work.  This issue and the second part of AMQ-776, are fixed now by your patch.  I'll update AMQ-776, too.


> Problem with subscription passing with network of brokers in AMQ 4.0.2
> ----------------------------------------------------------------------
>
>                 Key: AMQ-961
>                 URL: https://issues.apache.org/activemq/browse/AMQ-961
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: Kevin Yaussy
>            Priority: Critical
>         Attachments: RestartDFBOnResume.diff
>
>
> There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.
> 1) Start broker A (has a network connection to broker B)
> 2) Start broker B (has a network connection to broker A)
> 3) start consumer C against broker A, on FOO
> 4) start publisher P against broker B, on FOO
> Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.
> I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.
> Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
> e2ff000..0x8e2ff8f0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at java.lang.Object.wait(Object.java:474)
>         at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
>         - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
> .java:830)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
> geSupport.java:329)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
> .java:130)
>         at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
>         at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>         at java.lang.Thread.run(Thread.java:595)
> Stack trace of broker A when everything works correctly:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
>         at java.io.DataInputStream.readInt(DataInputStream.java:353)
>         at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
>         at java.lang.Thread.run(Thread.java:595)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] Assigned: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org
     [ https://issues.apache.org/activemq/browse/AMQ-961?page=all ]

Rob Davies reassigned AMQ-961:
------------------------------

    Assignee: Rob Davies

> Problem with subscription passing with network of brokers in AMQ 4.0.2
> ----------------------------------------------------------------------
>
>                 Key: AMQ-961
>                 URL: https://issues.apache.org/activemq/browse/AMQ-961
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: Kevin Yaussy
>         Assigned To: Rob Davies
>            Priority: Critical
>         Attachments: RestartDFBOnResume.diff
>
>
> There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.
> 1) Start broker A (has a network connection to broker B)
> 2) Start broker B (has a network connection to broker A)
> 3) start consumer C against broker A, on FOO
> 4) start publisher P against broker B, on FOO
> Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.
> I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.
> Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
> e2ff000..0x8e2ff8f0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at java.lang.Object.wait(Object.java:474)
>         at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
>         - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
> .java:830)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
> geSupport.java:329)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
> .java:130)
>         at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
>         at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>         at java.lang.Thread.run(Thread.java:595)
> Stack trace of broker A when everything works correctly:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
>         at java.io.DataInputStream.readInt(DataInputStream.java:353)
>         at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
>         at java.lang.Thread.run(Thread.java:595)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org
     [ https://issues.apache.org/activemq/browse/AMQ-961?page=all ]

Rob Davies resolved AMQ-961.
----------------------------

    Fix Version/s: 4.2.0
       Resolution: Fixed

Applied patch in SVN revision 491185

thanks kevin Yaussy!

> Problem with subscription passing with network of brokers in AMQ 4.0.2
> ----------------------------------------------------------------------
>
>                 Key: AMQ-961
>                 URL: https://issues.apache.org/activemq/browse/AMQ-961
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.0.2
>            Reporter: Kevin Yaussy
>         Assigned To: Rob Davies
>            Priority: Critical
>             Fix For: 4.2.0
>
>         Attachments: RestartDFBOnResume.diff
>
>
> There's an occasional problem with subscription propagation when using a network of brokers.  Test scenario uses ConsumerTool and PublisherTool in examples area of distribution.
> 1) Start broker A (has a network connection to broker B)
> 2) Start broker B (has a network connection to broker A)
> 3) start consumer C against broker A, on FOO
> 4) start publisher P against broker B, on FOO
> Messages do not flow to consumer C.  In the broker B log, there's no indication it got any subscriptions from broker A.  Again, this is occasional.
> I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine.  There's an obvious difference in one of the threads that hopefully will bring light to the problem.  I've not gone into the code yet to try and find the issue, but figured I would open this issue first.
> Stack trace of broker A when subscriptions did NOT pass, and message flow is broken:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8
> e2ff000..0x8e2ff8f0]
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at java.lang.Object.wait(Object.java:474)
>         at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179)
>         - locked <0x9b2b00d0> (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport
> .java:830)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid
> geSupport.java:329)
>         at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport
> .java:130)
>         at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
>         at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137)
>         at java.lang.Thread.run(Thread.java:595)
> Stack trace of broker A when everything works correctly:
> "ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112" prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0]
>         at java.net.SocketInputStream.socketRead0(Native Method)
>         at java.net.SocketInputStream.read(SocketInputStream.java:129)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49)
>         at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56)
>         at java.io.DataInputStream.readInt(DataInputStream.java:353)
>         at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
>         at java.lang.Thread.run(Thread.java:595)

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira