You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Ranjit Nethi (JIRA)" <ji...@apache.org> on 2016/10/05 15:59:21 UTC

[jira] [Created] (AMQ-6457) Durable Subscribers going offline - Over Network Of Brokers - Duplex Connection

Ranjit Nethi created AMQ-6457:
---------------------------------

             Summary: Durable Subscribers going offline - Over Network Of Brokers - Duplex Connection
                 Key: AMQ-6457
                 URL: https://issues.apache.org/jira/browse/AMQ-6457
             Project: ActiveMQ
          Issue Type: Bug
          Components: activemq-camel, networkbridge
    Affects Versions: 5.14.0, 5.13.3
         Environment: Active MQ Version 5.13.3
Karaf 4.0.6 
Camel 2.16.3 

-Active MQ brokers are deployed in Karaf container. 
-Cluster of Active MQ Brokers (Network of brokers, configured as HUB and SPOKES).
-Broker(s) at Hub (Master/Slave configuration using Shared File System)
- Broker(s) at spoke(s)- Connected to HUB using Duplex Network Connector ( Openwire/NIO) 
            Reporter: Ranjit Nethi


-Active MQ brokers are deployed in Karaf container. 
-Cluster of Active MQ Brokers (Network of brokers, configured as HUB and SPOKES).
-Broker(s) at Hub (Master/Slave configuration using Shared File System)
- Broker(s) at spoke(s)- Connected to HUB using Duplex Network Connector ( Openwire/NIO), one for topic and one for queue

Issue: We have durable subscriptions to topics on HUB and producers on Spokes. We are aware of network outages between the HUB and SPOKE brokers, sometimes we are experiencing multiple outages and as a result we see the topic subscribers end up as offline  and continue to store messages as the spoke broker. We are need a restart of the broker to reestablish the network bridge.

Relevant Logs: 

2016-09-22 14:21:40,105 | WARN  | tyMonitor Worker | DemandForwardingBridgeSupport    | 20 - org.apache.activemq.activemq-osgi - 5.13.3 | Network connection between vm://central-amq-broker#44 and tcp:///xx.xxx.xx.xx:53103@61616 shutdown due to a remote error: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp:///xx.xxx.xx.xx:53103

2016-09-22 14:21:40,117 | INFO  | -broker] Task-21 | DemandForwardingBridgeSupport    | 20 - org.apache.activemq.activemq-osgi - 5.13.3 | central-amq-broker bridge to T1-amq-broker stopped

2016-09-22 14:23:44,246 | INFO  | eMQ NIO Worker 4 | TransportConnection              | 20 - org.apache.activemq.activemq-osgi - 5.13.3 | Started responder end of duplex bridge T:broker1->broker2@ID:T1-35496-1474555572634-0:1
2016-09-22 14:23:44,255 | INFO  | al-amq-broker#52 | DemandForwardingBridgeSupport    | 20 - org.apache.activemq.activemq-osgi - 5.13.3 | Network connection between vm://central-amq-broker#52 and tcp:///xx.xxx.xx.xx:53162@61616 (T1-amq-broker) has been established.

Network Connector on Spoke Broker:


<networkConnectors>
         	<networkConnector 
	            name="T:broker1->broker2"
				userName="karaf"
		        password="karaf"
		        uri="masterslave:(tcp://${ACTIVEMQ_HEAD_1_IP_ADDRESS}:61616,tcp://${ACTIVEMQ_HEAD_2_IP_ADDRESS}:61616)"
        	    duplex="true"
	            decreaseNetworkConsumerPriority="true"
	            networkTTL="2"
        	    dynamicOnly="true">
	            <excludedDestinations>
        	          <queue physicalName="&gt;" />
        	          <topic physicalName="Shop.Pos.Api.Outbound" />
	            </excludedDestinations>
	         </networkConnector>
	         <networkConnector 
	            name="Q:broker1->broker2" 
				userName="karaf"
	            password="karaf"
	            uri="masterslave:(tcp://${ACTIVEMQ_HEAD_1_IP_ADDRESS}:61616,tcp://${ACTIVEMQ_HEAD_2_IP_ADDRESS}:61616)"
	            duplex="true"
	            decreaseNetworkConsumerPriority="true"
	            networkTTL="2"
	            dynamicOnly="true">
	            <excludedDestinations>
	                  <topic physicalName="&gt;" />
	            </excludedDestinations>
	         </networkConnector>
		</networkConnectors>


Test to Recreate:
To recreate this issue, we can block the network between the two hosts while simulating some load





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)