Please let me know if I should create a JIRA to track this issue / change.
I'm running on windows xp against AMQ 4.0.1. I have not yet tried to repro
on anything later.
In my environment, the producer is running in one JVM loaded via JNI
invokation with an embedded broker and a DemandForwardingBridge and failover
set to true that is connecting to the remote broker via
"tcp://128.0.0.1:61616".
The consumer and the BrokerService are running on the same machine but in
another JVM also loaded via JNI invokation but communicating with each other
via "vm://localhost". I've instantiated the broker, persistence adapter,
etc programatically, so I'm destroying them gracefully rather than through a
CTRL-C.
When the remote broker is shut down via CTRL-C, everything seems to work in
that the DemandForwardingBroker goes interrupted and then picks back up when
the broker comes back. It took AMQ-776 patch to get this to work, but it
does after that patch is applied.
However, when the remote broker is shut down gracefully, the
DemandForwardingBridge identifies explicitly that the remote broker has
shutdown (via a log message that I dont have handy right now) and it then
also shuts itself down by stopping it's background thread.
I've applied a local fix that seems to correct the problem, but I'm unsure
whether its a good fix overall. There were two new lines of code applied to
DemandForwardingBridgeSupport.java at line 491.
/*------------------------------------------------------------------------------------------
Beginning of modifications made by [EMAIL PROTECTED] It seems that when a
broker is gracefully shut down, it returns either an IllegalStateException
or an IOException back to any connected bridge (or any connection?). This
does not happen on an abrupt termination of the JVM (i.e. exit(), ctrl-c,
etc) which is the normal manner of shutdown for the standard ActiveMQ
distribution.
The behavior for this exception causes the the bridge) to shutdown its
background thread which is effectively equivalent to the bridge going "belly
up" and not being able to autorecover except to start it again. It is
probably better never to stop in the first place in this specific case as it
is unclear whether there is any feedback mechanism to tell the client that
the restart is necessary.
There may be unforeseen side-effects of this change so the intent was to
limit the scope of the change as much as possible. It is unclear whether
this behavior should further be limited such that it's enablement is tied
to whether the "failover" has been set or not.
*
------------------------------------------------------------------------------------------
*/
if ((er.getException() instanceof IllegalStateException) == false &&
(er.getException() instanceof IOException) == false)
/*-----------------------------------------------
* End of modifications made by [EMAIL PROTECTED]
* ----------------------------------------------
*/
--
View this message in context:
http://www.nabble.com/DemandForwardingBridge-with-failover%3D%3Dtrue-shuts-down-background-thread-when-remote-broker-gracefully-shuts-down-tf2632490.html#a7347304
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
