On 17 Apr 2008, at 00:51, Rukus520 wrote:
Hi,
I'd like to handle broker failure by queueing messages I'm sending
(for
transmission after reconnecting) instead of depending on a backup
broker. I
can either write code to do the queueing myself OR use an embedded,
in-process broker to do the queueing for me. The in-process broker
(A) can
forward messages to the remote broker (B) when broker B is
available, and
queue messages using the File Based Cursor when broker B is
unavailable.
In essense, I'm using the remote broker as my JMS provider, and I'm
considering using the in-process broker just to take advantage of
ActiveMQ's
built in queueing mechanism.
Is this usage of ActiveMQ appropriate? Why or why not?
If this is indeed a poor approach, is there any way to handle
queueing on
the message producer side without having to manually detect connection
failure, and implementing the queueing yourself?
Thanks in advance.
--
View this message in context:
http://www.nabble.com/ActiveMQ-Usage-tp16736018s2354p16736018.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
What you've outlined is perfectly valid usage scenario - and something
we usually recommend where you want local client persistence, and the
client not to block while the network/broker are not available
cheers,
Rob
http://open.iona.com/ -Enterprise Open Integration
http://rajdavies.blogspot.com/
