activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jrepko <>
Subject Re: Infinite loop if FailoverTransport is interrupted
Date Fri, 25 May 2007 09:05:20 GMT

I just ran into this problem as well.  I was thinking about the suggested
solution.  Wouldn't you want to throw to the outer catch instead?   

dgquintas wrote:
> Hi everybody,
> I have kind of a question regarding the Failover transport: let's assume
> one does not have direct access to the ActiveMQ mechanisms; instead,
> something like Lingo/Spring isolates the user from it. In this setup, if
> one want to abort the connection process to the broker (for instance,
> because it's down or its URL has been wrongly specified), an option would
> be to interrupt the ActiveMQ thread responsible for it (because we don't
> have access to the stop() method of the FailoverTransport class instance).
> But in doing so, we run into an endless loop:
> Line 344 onwards:
>     public void oneway(Object o) throws IOException {
>     	(...)
>                         // Wait for transport to be connected.
>                         while (connectedTransport == null && !disposed &&
> connectionFailure==null ) {
>                             log.trace("Waiting for transport to
> reconnect.");
>                             try {
>                                 reconnectMutex.wait(1000);
>                             }
>                             catch (InterruptedException e) {
>                                 Thread.currentThread().interrupt();
>                                 log.debug("Interupted: " + e, e);
>                             }
>                         }
> a catch is given for the InterruptedException event, but the interrupted
> condition is not checked on the while sentinel expression. As we cannot
> modify disposed or anything really (once again, because we don't have
> direct access to the transport object instance), we run into and endless
> loop situation. By simply appending ( &&
> !(Thread.currentThread().isInterrupted() ) to the while sentinel
> expression, this situation would go away. 
> What do you guys think? I might be missing something or plainly doing
> things the wrong way, but when using ActiveMQ from something like
> Lingo/Spring, this seems (to me) as the only way to give up trying to
> connect. By the way, using maxReconnectAttempts in the broker URL is not
> an option, as it is left to the user to determine at runtime when to give
> up trying (he/she is asked every n seconds if he/she wants to wait longer
> or bail out right away).
> Best regards,
> David.

View this message in context:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message