frame size eror: source F5 Loadbalancer

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

frame size eror: source F5 Loadbalancer

Stephen Ehlas

Hi

 

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:

 

=ERROR REPORT==== 22-May-2014::15:25:36 ===

AMQP connection <0.13650.16> (closed), channel 19793 - error:

{amqp_error,frame_error,

            "type 65, all octets = <<>>: {frame_too_large,1342177289,131064}",

            none}

 

=ERROR REPORT==== 22-May-2014::15:25:39 ===

closing AMQP connection <0.13650.16> (192.168.x.x:50614 -> 192.168.x.x:5672):

fatal_frame_error

 

=ERROR REPORT==== 22-May-2014::15:25:39 ===

AMQP connection <0.13665.16> (closed), channel 19793 - error:

{amqp_error,frame_error,

            "type 65, all octets = <<>>: {frame_too_large,1342177289,131064}",

            none}

 

=ERROR REPORT==== 22-May-2014::15:25:42 ===

closing AMQP connection <0.13665.16> (192.168.x.x:50615 -> 192.168.x.x:5672):

fatal_frame_error

 

On the client side we see this error:

 

15867 ERROR MassTransit.Context.ServiceBusReceiveContext - Consumer Exception Exposed

None of the specified endpoints were reachable

Endpoints attempted:

------------------------------------------------

endpoint=amqp-0-9://<HOSTNAME>:5672, attempts=1

RabbitMQ.Client.Exceptions.ProtocolVersionMismatchException: AMQP server protocol negotiation failure: server version unknown-unknown, client version 0-9

 

Has anyone seen this before?

 

Regards

 

Stephen Ehlas
Senior IT Systems Engineer

T:             +31 (0)20 521 89 50

M:           +31 (0)6 239 084 15
E:             [hidden email]

W:           www.albumprinter.org / www.werkenbijalbelli.nl

cid:image001.png@01CE607F.9C048CA0

Create your own photo book & make moments last a lifetime!

Silver Tower
Stationsplein 53-57, 1012 AB Amsterdam, The Netherlands
P.O. box 14606, 1001 LC Amsterdam, The Netherlands

Albumprinter operates with its consumer brand Albelli in The NetherlandsBelgiumGermanyFranceNorwaySweden and the United Kingdom

cid:image002.png@01CE607F.9C048CA0   cid:image003.png@01CE607F.9C048CA0   cid:image004.png@01CE607F.9C048CA0    cid:image005.png@01CE607F.9C048CA0    cid:image006.png@01CE607F.9C048CA0

 


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: frame size eror: source F5 Loadbalancer

Matthias Radestock-3
On 23/05/14 10:22, Stephen Ehlas wrote:

> 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:/
> /{amqp_error,frame_error,/
> /            "type 65, all octets = <<>>:
> {frame_too_large,1342177289,131064}",/
> /            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.

Matthias.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: frame size eror: source F5 Loadbalancer

Ben Hood
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