[jira] Created: (AMQ-1069) Setting maxInactivityDuration on broker to broker connections to value greater than 30 seconds doesn't work
Setting maxInactivityDuration on broker to broker connections to value greater than 30 seconds doesn't work --- Key: AMQ-1069 URL: https://issues.apache.org/activemq/browse/AMQ-1069 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.1.0 Environment: Linux RHEL 4 with Java 1.5 Reporter: Eric Wood Priority: Critical We are running AMQ in a configuration with embedded brokers on both the producer and consumer (broker to broker network communication). We have an extremely high latency network, which results in a large number of inactivity timeouts. Once we discovered how to set the timeout, we tried to set it to a value of 100 seconds which we believe will work better with our configuration and network. However, we observed that timeouts were still occuring after 30 seconds of inactivity. We tried setting the inactivity timeout value on both brokers and got the same result. We tried setting it to a value less than 30 (i.e. 10) and we saw timeouts occuring on that interval. Because of this, we believe that there must be a limit on the inactivity timeout value. If there is such a limit, could it be increased.? The 30 second value causes a large number of timeouts, which we believe causes a lower effective throughput than is truly possible with JMS/AMQ. -- 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
[jira] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[ https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_37499 ] Eric Wood commented on AMQ-734: --- Hiram, The issue was intermittent, so the best we can do is run it for long periods of time. So far we have run with 4.1 for over ten hours total, failed the network connection about 20 times, including both active and natural failures, and it has recovered every time and we had 0 message loss. With 4.0.2 we were successful in reproducing the error nearly every time we caused a failure. So it seems that the problem is resolved, but we still want to do more testing. We are noticing a large number of inactivity timeouts. Our network is fairly low bandwidth/high latency, so we were wondering if there is a way, or one could be added, to adjust the inactivity timeout value. We think we could improve our throughput if we didn't timeout so often. If you'd like, I'll open a separate JIRA case for this. Regards, Eric Network connections do not reconnect when using static: with failover=true -- Key: AMQ-734 URL: https://issues.apache.org/activemq/browse/AMQ-734 Project: ActiveMQ Issue Type: Bug Components: Connector Affects Versions: 4.0 Environment: winxp java1.5.6 Reporter: tao Assigned To: Hiram Chirino Priority: Critical Fix For: 4.2.0, 4.1.1 If I pull out RJ45 port from net card ,waiting a time ,then put RJ45 port net card .Network is resume.Other computer always throw errors and net channel can't work. -- 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
[jira] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[ https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_37307 ] Eric Wood commented on AMQ-734: --- To add some further clarification. We verified (via logs) that the receive side broker had timed out the send side broker. Then, when the send side broker tries to reconnect, the receive side broker says invalid client id apparently because it did not unregister the client when it timed out? During this test, we had numerous timeouts and successful recoveries, and then suddenly it broke down. Looking at the previous posts a little more closely, I am now wondering if this is a different issue? Should I create a new issue? Network connections do not reconnect when using static: with failover=true -- Key: AMQ-734 URL: https://issues.apache.org/activemq/browse/AMQ-734 Project: ActiveMQ Issue Type: Bug Components: Connector Affects Versions: 4.0 Environment: winxp java1.5.6 Reporter: tao Assigned To: Hiram Chirino Priority: Critical Fix For: 4.0.1, 4.1 If I pull out RJ45 port from net card ,waiting a time ,then put RJ45 port net card .Network is resume.Other computer always throw errors and net channel can't work. -- 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
[jira] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[
https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_37294 ]
Eric Wood commented on AMQ-734:
---
We can reproduce this issue using the current build of 4.0.2. We are running a
distributed queue between two embedded brokers over an unreliable network
(wireless). We had been using 4.0.1, but the brokers did not reestablish the
bridge when it was stopped due to inactivity timeout. We tried 4.0.2 and it
worked great for a while, but eventually one of the reconnect attempts failed.
On the receiver side broker (called CTSServer) we see in the logs wire format
negotiation taking place, but on the send side broker (called CTSClient) we get
the following in the log:
[java] 12:42:12,236 DEBUG DurableConduitBridge:69 - Forwarding messages
for durable destination: queue://TEST.FOO
[java] 12:42:12,237 DEBUG DemandForwardingBridge:289 - stopping CTSClient
bridge to CTSServer is disposed already ? false
[java] 12:42:12,240 DEBUG DemandForwardingBridge:308 - CTSClient bridge to
CTSServer stopped
[java] 12:42:12,241 DEBUG DemandForwardingBridge:289 - stopping CTSClient
bridge to CTSServer is disposed already ? true
[java] 12:42:12,242 DEBUG DemandForwardingBridge:308 - CTSClient bridge to
CTSServer stopped
[java] 12:42:12,244 INFO NetworkConnector:96 - Establishing network
connection between from vm://CTSClient?network=true to tcp://10.134.0.1:61616
[java] 12:42:15,986 DEBUG WireFormatNegotiator:65 - Sending:
WireFormatInfo { version=1, properties={TightEncodingEnabled=true,
TcpNoDelayEnabled=true, SizePrefixDisabled=false, StackTraceEnabled=true,
MaxInactivityDuration=3, CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[java] 12:42:15,987 DEBUG TcpTransport:133 - TCP consumer thread starting
[java] 12:42:18,957 DEBUG WireFormatNegotiator:95 - Received WireFormat:
WireFormatInfo { version=1, properties={StackTraceEnabled=true,
TightEncodingEnabled=true, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
MaxInactivityDuration=3, CacheEnabled=true}, magic=[A,c,t,i,v,e,M,Q]}
[java] 12:42:18,957 DEBUG WireFormatNegotiator:102 -
tcp:///10.134.0.1:61616 before negotiation: OpenWireFormat{version=1,
cacheEnabled=false, stackTraceEnabled=false, tightEncodingEnabled=false,
sizePrefixDisabled=false}
[java] 12:42:18,958 DEBUG WireFormatNegotiator:113 -
tcp:///10.134.0.1:61616 after negotiation: OpenWireFormat{version=1,
cacheEnabled=true, stackTraceEnabled=true, tightEncodingEnabled=true,
sizePrefixDisabled=false}
[java] 12:42:21,838 DEBUG Service:221 - Async error occurred:
javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
NC_CTSServer_inboundCTSClient already connected
[java] javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
NC_CTSServer_inboundCTSClient already connected
[java] at
org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:180)
[java] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:70)
[java] at
org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:70)
[java] at
org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:70)
[java] at
org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:83)
[java] at
org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:633)
[java] at
org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:120)
[java] at
org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:237)
[java] at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:61)
[java] at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92)
[java] at
org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67)
[java] at
org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:77)
[java] at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:45)
[java] at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:59)
[java] at
org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:225)
[java] at
org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:191)
[java] 12:42:21,840 INFO DemandForwardingBridge:230 - Network connection
between vm://CTSClient#728 and tcp:///10.134.0.1:61616(CTSServer) has been
established.
[java] 12:42:21,851 INFO DemandForwardingBridge:432 - Network connection
between vm://CTSClient#728 and tcp:///10.134.0.1:61616 shutdown due to a local
error: javax.jms.InvalidClientIDException: Broker: CTSClient - Client:
