activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira <mte...@tid.es>
Subject Re: QueueBridge and remote broker reconnections
Date Thu, 28 Sep 2006 15:44:26 GMT
<!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&oacute;:
<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&nbsp; the attempt to
implement&nbsp; 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&nbsp; we can see:<br>
<br>
<tt>try {<br>
&nbsp;&nbsp;&nbsp; listener.onMessage(message);<br>
&nbsp;&nbsp;&nbsp; afterMessageIsConsumed(md, false);<br>
} catch (RuntimeException e) {<br>
&nbsp;&nbsp;&nbsp; if ( session.isDupsOkAcknowledge() || session.isAutoAcknowledge()
)
{<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Redeliver the message<br>
&nbsp;&nbsp;&nbsp; } else {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // Transacted or Client
ack: Deliver the next message.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; afterMessageIsConsumed(md,
false);<br>
&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp; 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>
&nbsp;&nbsp;&nbsp; log.error("failed to forward message on attempt: " + (++attempt)
+
" reason: " + e + " message: " + message, e);<br>
&nbsp;&nbsp;&nbsp; if (maximumRetries &gt; 0 &amp;&amp; attempt &gt;=
maximumRetries) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
stop();<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; catch (Exception e1)
{<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
log.warn("Failed to stop cleanly", e1);<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
&nbsp; }<br>
<b>&nbsp; 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>

Mime
View raw message