Comments on: How do you do, that voodoo, that Queues Do? http://fewbar.com/2010/01/queue-voodoo-that-queues-do/ Technology, life, and mischief, not in that order Sat, 27 Mar 2010 11:49:20 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Bruce Snyder http://fewbar.com/2010/01/queue-voodoo-that-queues-do/comment-page-1/#comment-265 Bruce Snyder Sat, 23 Jan 2010 20:25:18 +0000 http://fewbar.com/?p=136#comment-265 Ah, yes, that's a very different scenario and is known by a few names including infinite failover and continuous availability. This feature is not available in ActiveMQ largely because it's a very difficult problem to solve for many reasons. Some of the commercial MOMs have solved this and that's partially why they cost so much money. But they also come with some very costly requirements to make such a feature work, too. Thanks for the clarification. Bruce Ah, yes, that’s a very different scenario and is known by a few names including infinite failover and continuous availability. This feature is not available in ActiveMQ largely because it’s a very difficult problem to solve for many reasons. Some of the commercial MOMs have solved this and that’s partially why they cost so much money. But they also come with some very costly requirements to make such a feature work, too. Thanks for the clarification.

Bruce

]]> By: clint http://fewbar.com/2010/01/queue-voodoo-that-queues-do/comment-page-1/#comment-264 clint Sat, 23 Jan 2010 05:52:35 +0000 http://fewbar.com/?p=136#comment-264 Bruce, I wasn't very clear in the article above. What I was referring to was the procedure required to recover with a pure Master/Slave. http://activemq.apache.org/pure-master-slave.html As I said, I'm not looking for the big enterprise solution where I have a SAN or a big NFS appliance that I trust not to die (a really nice Linux or FreeBSD server running nfs doesn't count). With pure master/slave, when the master fails the slave takes over and conceivably your stomp clients could be made to use it. However, when the master comes back online, according to the link above: "# A failed master cannot be re-introduced without shutting down the the slave broker (no automatic failback) # There is no automatic synchronization between brokers. This is a manual process." And the procedure: "This is a manual process - once a master has failed, the only sure way to ensure that the toplogy is synchronized again is manually: * shutdown the slave broker (The clients do not need to be shutdown - they will wait until the topology is re-established if they are failover clients * copy the data directory from the slave over the data directory of the master broker * re-start the master and the slave " Stomp doesn't really have the "failover" bit builtin, though it can be made to do it more or less. My issue with this is that one of the big points of using a queueing system is to be able to quickly dump messages into it and forget about them, trusting that a backend process will receive it. But if I have to wait while a big backed up queue is synchronized, even if its just for 1 minute.. thats 1 minute of browser spinning, or errors due to timeouts. Bruce,

I wasn’t very clear in the article above. What I was referring to was the procedure required to recover with a pure Master/Slave.

http://activemq.apache.org/pure-master-slave.html

As I said, I’m not looking for the big enterprise solution where I have a SAN or a big NFS appliance that I trust not to die (a really nice Linux or FreeBSD server running nfs doesn’t count).

With pure master/slave, when the master fails the slave takes over and conceivably your stomp clients could be made to use it. However, when the master comes back online, according to the link above:

“# A failed master cannot be re-introduced without shutting down the the slave broker (no automatic failback)
# There is no automatic synchronization between brokers. This is a manual process.”

And the procedure:

“This is a manual process – once a master has failed, the only sure way to ensure that the toplogy is synchronized again is manually:

* shutdown the slave broker (The clients do not need to be shutdown – they will wait until the topology is re-established if they are failover clients
* copy the data directory from the slave over the data directory of the master broker
* re-start the master and the slave
”

Stomp doesn’t really have the “failover” bit builtin, though it can be made to do it more or less.

My issue with this is that one of the big points of using a queueing system is to be able to quickly dump messages into it and forget about them, trusting that a backend process will receive it.

But if I have to wait while a big backed up queue is synchronized, even if its just for 1 minute.. thats 1 minute of browser spinning, or errors due to timeouts.

]]> By: Bruce Snyder http://fewbar.com/2010/01/queue-voodoo-that-queues-do/comment-page-1/#comment-262 Bruce Snyder Fri, 22 Jan 2010 15:34:21 +0000 http://fewbar.com/?p=136#comment-262 Actually, you don't need to shut down ActiveMQ for the master/slave to reconnect. You just need to configure the connection between them using the failover transport and it works like a charm. This feature was added in the ActiveMQ 5.3.0 release. In fact, I just tested this last week for use in a network of brokers in ActiveMQ. The write-up of it is available on my blog: http://bit.ly/6loIOu Actually, you don’t need to shut down ActiveMQ for the master/slave to reconnect. You just need to configure the connection between them using the failover transport and it works like a charm. This feature was added in the ActiveMQ 5.3.0 release. In fact, I just tested this last week for use in a network of brokers in ActiveMQ. The write-up of it is available on my blog:

http://bit.ly/6loIOu

]]>