You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2011/08/31 14:22:09 UTC

[jira] [Closed] (AMQ-3480) Channel was inactive for too long when client and broker aren't correctly time synchronized.

     [ https://issues.apache.org/jira/browse/AMQ-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish closed AMQ-3480.
-----------------------------

    Resolution: Duplicate

This is most like a duplicate of AMQ-3414.  Try using a nightly SNAPSHOT of 5.6

> Channel was inactive for too long when client and broker aren't correctly time synchronized.
> --------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3480
>                 URL: https://issues.apache.org/jira/browse/AMQ-3480
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.4.2
>         Environment: ActiveMQ Client : 4.1.2
> ActiveMQ broker : 5.4.2
> Machine A and B run over Window
>            Reporter: David Wursteisen
>
> Hello, 
> We encurred an issue with activeMQ 5.4.2 : 
> We've got a activeMQ client (version 4.1.2) which is connected to a activeMQ broker 5.4.2. After few minutes, we've got this stacktrace in the broker : 
> {quote}
> 2011-08-29 16:41:12,844 INFO  [org.apache.activemq.transport.failover.FailoverTransport] Transport failed, attempting to automatically reconnect due to: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long.
> org.apache.activemq.transport.InactivityIOException: Channel was inactive for too long.
> 	at org.apache.activemq.transport.InactivityMonitor.readCheck(InactivityMonitor.java:102)
> 	at org.apache.activemq.transport.InactivityMonitor.access$000(InactivityMonitor.java:35)
> 	at org.apache.activemq.transport.InactivityMonitor$1.run(InactivityMonitor.java:51)
> 	at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:431)
> 	at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.runAndReset(FutureTask.java:198)
> 	at edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:189)
> 	at edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:213)
> 	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> 	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> 	at java.lang.Thread.run(Thread.java:595)
> 2011-08-29 16:41:12,860 INFO  [org.apache.activemq.transport.failover.FailoverTransport] Transport failed, attempting to automatically reconnect due to: java.net.SocketException: socket closed
> java.net.SocketException: socket closed
> 	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:267)
> 	at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:156)
> 	at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136)
> 	at java.lang.Thread.run(Thread.java:595)
> {quote}
> We first thinking that it was a network issue, but we just discovered that the machine where the broker is runing isn't correctly time synchronized. For example : 
> at 14:00, it's 14:00 on the machine, but at 14:30, it will be 14:50, then NTP service will set the time to 14:30....
> With an activeMQ 4.1.2 for the broker, we didn't get this issue. So, for us, this is a regretion (even if the time problem on the broker machine isn't helping)
> To reproduce the problem : 
> create a standard broker on computer A
> create a standard client on computer that will be connected to the computer A using failover transport.
> after several time, change the time on computer A (ie : it's 14:00:00, set the time to 13:00:00)
> After several seconds, the client & the broker will close the connection with the message Channel was inactive for too long.
> Regards

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira