[prev in list] [next in list] [prev in thread] [next in thread]
List: activemq-users
Subject: Re: QueueBridge and remote broker reconnections
From: Manuel Teira <mteira () tid ! es>
Date: 2006-09-28 15:44:26
Message-ID: 451BEDDA.4030704 () tid ! es
[Download RAW message or body]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Manuel Teira escribió:
<blockquote cite="mid451A9A54.2080906@tid.es" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
I'm sad to confirm this behaviour with the last changes:<br>
<br>
1.-Start the remote broker.<br>
2.-Start the activemq broker with a queued bridge.<br>
3.-Send a message to the bridged queue: The message is bridged
correctly.<br>
4.-Stop the remote broker.<br>
5.-Send a message to the bridged queue. It fails on
QueueBridge.sendMessage as the producer is closed.<br>
6.-Send a new message to the bridged queue. After the last changes, it
tries to call 'restartProducer' but it fails, because the remote broker
is down.<br>
7.-Start the remote broker.<br>
8.-Send a new message to the bridged queue. restartProducer is called
again, the producer and its connection are successfully recreated. But
ONLY the new message reaches the remote broker. I don't see any attempt
to send the old ones. In the JMX console, I can see, for this queue:<br>
<br>
ConsumerCount: 1<br>
DequeueCount: 4<br>
EnqueueCount: 4<br>
QueueSize: 0<br>
<br>
</blockquote>
I think that perhaps this problem was created by the attempt to
implement reconnections:<br>
<br>
To be able to reconnect to the remote broker, DestinationBridge is
capturing any exception that could be produced during message
delivering (onMessage). Tipically RuntimeExceptions like
IllegalStateException (if the consumer is closed) or a
NullPointerException in a recently corrected bug. <br>
I think that before those changes, these RuntimeExceptions probably
were reaching the code in ActiveMQMessageConsumer.dispatch method
(upper in the stack), where we can see:<br>
<br>
<tt>try {<br>
listener.onMessage(message);<br>
afterMessageIsConsumed(md, false);<br>
} catch (RuntimeException e) {<br>
if ( session.isDupsOkAcknowledge() || session.isAutoAcknowledge() \
) {<br>
// Redeliver the message<br>
} else {<br>
// Transacted or Client ack: Deliver the \
next message.<br> \
afterMessageIsConsumed(md, false);<br> }<br>
log.warn("Exception while processing message: " + e, e);<br>
}</tt><br>
<br>
As far as the exception is not reaching this level, message delivering
is assumed successful. I think that this is what is happening as far as
I never see the log "Exception while processing message..." when the
bridged remote broker is down and I send a message.<br>
<br>
So, I've added a dirty and fast fix to DestinationBridge.onMessage(),
just rethrowing any catched exception as a RuntimeException:<br>
<br>
<tt>catch (Exception e) {<br>
log.error("failed to forward message on attempt: " + (++attempt) +
" reason: " + e + " message: " + message, e);<br>
if (maximumRetries > 0 && attempt >= maximumRetries) \
{<br> try {<br>
stop();<br>
}<br>
catch (Exception e1) {<br>
log.warn("Failed \
to stop cleanly", e1);<br> }<br>
}<br>
<b> throw new RuntimeException(e);</b><br>
}<br>
</tt><br>
Now, the exception is reaching this level (I see the exception log now)
but the message is not redelivered, I think that it's caused because
the condition:<br>
<br>
<tt> session.isDupsOkAcknowledge() || session.isAutoAcknowledge()<br>
<br>
</tt>is not reached. <br>
<br>
So, my question is:<br>
<br>
Why the session with the remote broker is not reaching these
conditions? Do this mean that for a remote bridged broker, message send
failures are never retried?<br>
<br>
<br>
Regards.<br>
<br>
<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic