In the regular tcp: case, the receive sends an async command to the
broker and then blocks on the internal consumer queue, if that async
send were to fail you would need an exception listener to capture it.
The failover transort traps all exceptions on async/oneway requests so
it will notice by def
Hello,
thanks, its seems to work around our problem, we will keep an eye on
it. Are there any reason while failover: connection is capable of
detecting the network problem and reconnecting while the tcp: just
"wait"? Shouldn't it at least throw an exception when link is down?
Le 03/08/10 1
Hi David,
failover transport can be used for just one broker as well and it is
used to solve these kind of problems. So
failover:(tcp://localhost:61616)
should work just fine. If the broker is down or there are network
problems, the transport will try to reestablish the connection.
Cheers
--
Thanks for reply
we do not use failover, because there is only one broker. It's not
critical enough to justify two or more brokers. We just want receive()
to fail in a way or other when the other ends (broker) dies for some
reason, so we can take appropriate measures. This is just illogical fo
Hi David,
did you try using failover transport
http://activemq.apache.org/failover-transport-reference.html
It should take care of detecting network problems and reconnecting.
Then you should just use receive() or message listener
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source
Hello,
we are having fiability troubles with activeMQ (5.2). To get around
those, we use in consumer receive(timeout) with a timeout of 60 seconds
to detect early problems with broker. We assumed if we called receive()
on a closed connection (broker side closed) we sould somehow get an
excep
