You're the expert, should it work? :)
This should work:
Enabling heartbeats (when connecting with a client) didn't help?
(heartbeats are the AMQP equivalent of TCP keep-alives)
Adding this to the rabbit entry in rabbitmq.config (yes, you also need
to respecify the default rabbit options) enables keep-alive on the
sockets.

{tcp_listen_options, [binary,
{packet, raw},
{reuseaddr, true},
{backlog, 128},
{nodelay, true},
{exit_on_close, false},
{keepalive, true}]}

I don't know whether this is enough to prevent your firewall from
terminating the "idle" connections.

Cheers,
Alex
On Tue, Jan 03, 2012 at 11:16:20AM -0500, Mark Steele wrote:
You're the expert, should it work? :)

I haven't tested that out, hadn't occurred to me to try.

On Tue, Jan 3, 2012 at 11:06 AM, Alexandru Scvor?ov
wrote:
We've been bitten by this with firewalls that close connections after idle
timeouts. Best solution I can come up with is to use TCP keepalives.
Enabling heartbeats (when connecting with a client) didn't help?
(heartbeats are the AMQP equivalent of TCP keep-alives)
If you client supports setting TCP options during the connection, that's
all you need to do for the client side part. For the server side, I
couldn't find any options for this in the rabbit config, so we
implemented
libkeepalive to force the server to use keepalives.

Rabbit folks, please add this as an option to the server.
I haven't tried, but I think you can enable keepalives in the
rabbitmq.config. Just add a tcp_listen_options entry with {keepalive,
true}:

[
{rabbit, [{tcp_listen_options, [{keepalive, true}]}]}
].

http://www.rabbitmq.com/configure.html#config-items

Wouldn't something like that work?

Cheers,
Alex
On Tue, Jan 03, 2012 at 10:47:43AM -0500, Mark Steele wrote:
We've been bitten by this with firewalls that close connections after idle
timeouts. Best solution I can come up with is to use TCP keepalives.

If you client supports setting TCP options during the connection, that's
all you need to do for the client side part. For the server side, I
couldn't find any options for this in the rabbit config, so we
implemented
libkeepalive to force the server to use keepalives.

Rabbit folks, please add this as an option to the server.

Cheers,

Mark Steele, CISSP, CSM
Bering Media Inc.

On Tue, Jan 3, 2012 at 9:41 AM, Alexandru Scvor?ov
wrote:
With 100's of computers connected to rabbitmq with persistent
connections,
would this pose any problems?
Not unless you run out of free file handles. On normal installations,
it should handle up to thousands of connections without difficulty.
You
could further configure it to support more connections.
Does it time-out by default?
No. Connections are not timed out.
Why use a heartbeat? Is it to re-establish if the heartbeat fails?
If the network fails between a client and the broker, and there's no
traffic between them at that point, both will think the connection is
still open, even though it isn't. Heartbeats ensure that both broker
and client are notified fairly quickly if the connection fails.
Would it be better for clients to close connections and only open a
connection when necessary?
It depends on your use case.
For reading messages we need persistent connections.
But for writing, and I can see how we could potentially only open a
connection to write a message when required.
For consuming messages *efficiently*, you need persistent connections.
If you only get messages very rarely, you could open a connection, poll
the broker with basic.get and then close the connection. But, if you
need to consume a lot of messages, you probably want persistent
connections anyway.

Hope this helps.

Cheers,
Alex
On Thu, Dec 29, 2011 at 05:21:26PM -0500, S Ahmed wrote:
With 100's of computers connected to rabbitmq with persistent
connections,
would this pose any problems?

Does it time-out by default?

Why use a heartbeat? Is it to re-establish if the heartbeat fails?

Would it be better for clients to close connections and only open a
connection when necessary?

For reading messages we need persistent connections.

But for writing, and I can see how we could potentially only open a
connection to write a message when required.
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 6 | next ›
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedDec 29, '11 at 10:21p
activeJan 4, '12 at 8:44a
posts6
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2018 Grokbase