Closed GoogleCodeExporter closed 9 years ago
It's worth noting that AMQP doesn't specify any kind of connection keep-alive
behaviour. Between deliveries, a connection can be silent for an arbitrarily
long time. Therefore, setting SO_TIMEOUT may result in spurious disconnections
of an otherwise-working socket.
During the initial connection phase, things are different: both peers are
expected to emit a certain sequence of frames reasonably immediately (the
protocol operates in what amounts to a request-response mode briefly). During
this negotiation phase, SO_TIMEOUT can actually do something useful if one peer
goes away without saying goodbye.
Original comment by angrybal...@gmail.com
on 16 Aug 2010 at 10:55
(Well, almost, Per bug #3, there's some heartbeat support in AMQP. It's not
active by default, though.)
Original comment by angrybal...@gmail.com
on 16 Aug 2010 at 10:56
Thanks for pointing that out. I was only thinking about sending events, not
the persistent consumer connections.
Original comment by jbalog...@gmail.com
on 16 Aug 2010 at 11:18
I think I agree with angrybal...@ on this point, that having a timeout after
the connection is established would be bad. The meaning of the connect_timeout
parameter is really just for the initial connection.
Original comment by barry.pe...@gmail.com
on 28 Mar 2011 at 5:27
Original issue reported on code.google.com by
jbalog...@gmail.com
on 16 Aug 2010 at 9:28