Our system sends small messages (1k) frequently, as data changes in the system, to serve as notifications to listeners. The "users" (serving as both producer and consumer) of these notifications are either human users or batch processes. The humans process records slowly with pause times while batch jobs process records quickly. It is hoped that messages can be received within 100ms of being sent.
The scenario we have is non-persistent messages and non-durable subscriptions. At system startup there will be dozens-hundreds of consumers connecting and remaining connected "forever". The message stream is a constant chatter of notification messages. Fast delivery of messages to interested subscriber is critical. 1. I see; I am thinking now that I have been delusional and that my tests are not yet sufficient to prove the behavior that I require :) 2. I do not anticipate large backlogs of undelivered messages to accumulate in the broker. Thanks for the warning though. Is there some better alternative to kahadb that you prefer? Leveldb sounds more "experimental" to me in my readings (at least, it is more complex to setup). 3. Interesting. I was dreaming of a "instantaneous" failover that might not introduce a huge bump in latency when the failover occurs. Pipe dream? Maybe, especially if I now need to enable persistent messages to guarantee message delivery in case of a failover. Thank you for your advice! -- View this message in context: http://activemq.2283324.n4.nabble.com/Failover-and-non-persistent-messages-tp4676862p4676972.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
