activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Bartel (JIRA)" <>
Subject [jira] Commented: (AMQ-1771) Failover transport should always signal resume of transport
Date Fri, 20 Jun 2008 05:23:00 GMT


Jan Bartel commented on AMQ-1771:

Hi Rob,

A jetty hightide user has posted me the following problem description, which I think may be
fixed by the patches above, but I'm not entirely sure - could you confirm for me if that's
the case?

Here's the problem as it was reported:

The Main thread is stuck waiting for ActiveMQConnection.brokerInfoReceived CountDownLatch
in the ActiveMQConnection.waitForBrokerInfo() method. The brokerInfoReceived latch is released
when the ActiveMQConnection.onCommand().processBrokerInfo() Listner event is received.

When the FailoverTransport is instantiated it immediately attempts to connect to the brokers.
On successful connection to the broker it calls the Listener, if one is attached.
The processBrokerInfo command from the broker is sent to the listener, in this case the ActiveMQConnection
which releases the latch.

The sequence of wiring the connection to the transport is as follows...
- ActiveMQConnectionFactory.createActiveMQConnection() creates the transport, then creates
the ActiveMQConnection(transport)
- The ActiveMQConnection constructor calls transport.setTransportListener(this) which attaches
the connection listener to the transport
- Finally the factory calls start() on the transport

The problem is the FailoverTransport starts to connect doReconnect() at construction time
using its own thread. On successful connection to the broker it notifies using the listener
but only if the listener is set. The race condition occurs on the main thread to attach the
listener to the FailoverTransport before the FailoverTransport connects. If the FailoverTransport
connects and the listener is not connected, notification messages are lost.."

ta muchly,

> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>                 Key: AMQ-1771
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.1.0
>         Environment: WinXP, JDK5
>            Reporter: Andreas Kuhtz
>            Assignee: Rob Davies
>             Fix For: 5.2.0
>         Attachments: amq-failover-reconnect.patch, amq-failover.patch
> The FailoverTransport does currently not signal the initial resume of the transport (due
to race condition) nor the failure (if maxReconnectAttempts is 0) and therefore we don't know
if the connection is successfully connected or not.
> The attached patch adds a sleep (copied from the failure processing part some lines below)
that ensures that the ??transportListener?? is set and the ??transportListener.transportResumed()??
is called.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message