Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <10799543.post@talk.nabble.com>
Date: Fri, 25 May 2007 02:05:20 -0700 (PDT)
From: jrepko <jay.repko@gmail.com>
To: dev@activemq.apache.org
Subject: Re: Infinite loop if FailoverTransport is interrupted
In-Reply-To: <10622964.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <10622964.post@talk.nabble.com>


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:
> 
> org.apache.activemq.transport.failover.FailoverTransport.java
> 
> 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: http://www.nabble.com/Infinite-loop-if-FailoverTransport-is-interrupted-tf3758516s2354.html#a10799543
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.