activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (Resolved) (JIRA)" <>
Subject [jira] [Resolved] (AMQ-3719) Tracked command IOException causes FailoverTransport to hang until failure occurs for untracked command
Date Wed, 14 Mar 2012 21:32:40 GMT


Timothy Bish resolved AMQ-3719.

    Resolution: Fixed
      Assignee: Timothy Bish

Fixed on trunk, thanks for doing the leg work on this one.
> Tracked command IOException causes FailoverTransport to hang until failure occurs for
untracked command
> -------------------------------------------------------------------------------------------------------
>                 Key: AMQ-3719
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>         Environment: Intel(R) Core(TM) i5 CPU M 540 @2.53GHz
> 8 GB, 64-bit
>            Reporter: Martin Serrano
>            Assignee: Timothy Bish
>            Priority: Critical
>             Fix For: 5.6.0
>         Attachments: amq-3719.patch
> I have only encountered this failure when the broker is experiencing heavy load and a
new connection attempt is made.
> * The FailoverTransport tracks commands that have been issued so that it can restore
the state upon a failure/reconnect event.
> * If an IOException occurs when sending a tracked command, the oneway() method returns,
assuming that the IOException is indicative of a transport failure and will result in a failure/reconnect
> * Some IOExceptions (like WireFormatNegotiation timesouts) are not always indicative
of transport failure however.  In this case since no subsequent failure/reconnect event occurs,
the command will never be resent.  If this is a synchronous command (like that generated by
starting a connection) the calling thread will hang.
> Incidentally, my reading of the code is that only non-tracked commands can generate the
IOException that triggers the handleTransportFailure command.  Is that what we really want?
> My belief is that the IOExceptions should always result in the triggering of the handleTransportFailure,
regardless of origin.
> I will attach a unit test and fix shortly.  The test will often fail (i.e. hang) without
the fix, but not always since I use a wireFormat.maxInactivityDurationInitalDelay=1 option
to trigger the behavior.  If the system runs fast enough, it sometimes will not get the timeout.
 I wasn't sure exactly how such a test should be written...The test will fail if connection
does not succeed within 60s

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message