We have a curious situation with RabbitMQ. When the clients try to connect directly to a rabbitMQ node, all is ok. When we pass them through our F5 load balancer, the 3rd connection attempt is aborted. The load balancer is set
to round robin. In the RabbitMQ logs we see this:
> We have a curious situation with RabbitMQ. When the clients try to
> connect directly to a rabbitMQ node, all is ok. When we pass them
> through our F5 load balancer, the 3^rd connection attempt is aborted.
> The load balancer is set to round robin. In the RabbitMQ logs we see this:
> /=ERROR REPORT==== 22-May-2014::15:25:36 ===/
> /AMQP connection <0.13650.16> (closed), channel 19793 - error:/
> / "type 65, all octets = <<>>:
> / none}/
This indicates that an AMQP protocol header - i.e.
'A','M','Q','P',0,0,9,1 - was sent on a connection that has already gone
through that handshake.
My guess is that the load balancer is routing a new client connection to
an existing server connection.
On Wed, May 28, 2014 at 9:20 AM, Matthias Radestock
<[hidden email]> wrote:
> My guess is that the load balancer is routing a new client connection to an
> existing server connection.
What's the general take on using F5 to maintain a transparent unbroken
AMQP conversation between a client and a set of individual cluster
nodes? Say for example one of the nodes dies to which a client had an
open connection to (via F5), is F5 smart enough to re-route the
existing AMQP conversation to another node in such a way that the
neither the server nor the client notice this?
rabbitmq-discuss mailing list
[hidden email] https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss