[rabbitmq-discuss] =?utf-8?Q?Help=EF=BC=8Cquestion_?=about =?utf-8?Q?rabbitmq+Haproxy=EF=BC=8Cclient_?=java

[Michael Klishin]

On 22 July 2014 at 12:20:46, Aaron (584911644 at qq.com) wrote:
> > so that can keep all messages complete no matter when the related  
> server or app is down.Such like，another node will work still  
> and keep the produce、customer healthy when a node is down.
> So，i have considered a solution to protect from losting messages,it‘s  
> rabbitmq（mirrored queue）+Haproxy.

There are *many* things that may fail and HAproxy won't protect you from
many of them. See

http://www.rabbitmq.com/ha.html
http://www.rabbitmq.com/reliability.html
http://www.rabbitmq.com/partitions.html
http://www.rabbitmq.com/nettick.html

You have to use publisher confirms:

http://www.rabbitmq.com/confirms.html

and be ready to reconnect and re-try publishes. In case the client
itself may crash between re-publishes, you may also need to keep a write-ahead log
(WAL) for messages. Yes, 100% guaranteed delivery is much harder than just adding
HAproxy to the mix.

> But，java code is not enough fortunately，LOL... Testing for  
> several times，and I get a result，that is java code doesn‘t work  
> at all in HA,but only load balancing....，during testing，when  
> I down a random node，producer will throw out a related session  
> error.
> Having troubled me for almost one week this problem，and looking  
> sincerely forward to ur reply.

Sorry, can you explain what "a related session error" is? If you lose a node,
HAproxy will detect that a backend is down after a moment of time. RabbitMQ
connections have a certain amount of state (e.g. active consumers and delivery tag
counters), so you need to recover them.

This is much easier for consumers, though. In recent RabbitMQ versions, consumers
will be re-subscribed if the queue master node fails. In other words, if you are
not connected to the failed node, you won't have to basic.consume again, RabbitMQ
will do it for you.

Starting with RabbitMQ Java client 3.3, there's an automatic connection/channel/topology recovery
feature:

http://www.rabbitmq.com/api-guide.html

which is usually sufficient for recovering consumers. However, the client itself does not
perform internal queueing of outgoing messages, so in the period of time that the connection
is down, you need to accumulate messages in a collection/queue in memory
and re-send them with confirmation checking. 
--  
MK  

Staff Software Engineer, Pivotal/RabbitMQ