search

veegee / amqpy

Pure-Python 2 & 3 AMQP client library
http://amqpy.readthedocs.org/
Other
32 stars 5 forks source link

Enh/Fix: make the heartbeat thread actively verify the last_heartbeat… #24

Open gst opened 9 years ago

gst commented 9 years ago

…_received

If server fails to send us its heartbeat, we should assume it's dead/gone.

NB: The heartbeat thread doesn't execute drain_events() calls, so the user - if he activated the heartbeat - must know that he should frequently (at least once every connection._heartbeat_final) call drain_events() so that the server heartbeats are read and accounted.

gst commented 9 years ago

NB: This is a proposed PR,

because I'm not sure this is the best to do, I mean :

Couldn't the heartbeat thread itself somehow calls drain_events() (or a submethod of it) so that it reads and accounts the server heartbeats, without interferring with the connection channels ??

That would really be better than excpecting the user to call himself drain_events() at a sufficient frequency.. (I recall that having an auto heartbeart (thread) is to be able to open a connection and be able to forget about it but still be sure to have it stay open as long as possible : as long as the rabbit server is up, and not as long as any other intermediate layer would decide it).

wdyt ?

gst commented 9 years ago

From my perspective I do think (but not 100% sure) that we should be able to do drain_events(0) in the heartbeat thread without that having an impact on any other(s) thread(s) using the same connection.. thanks of how the methods/events are dispatched from the server to the different channels..

If you think as me : I'll happily change the PR with that..

gst commented 9 years ago

ah, found maybe certainly a better method: a less "intrusive" way would/could be to apparently "simply" open a new channel and directly close it, that involves a communication with the server but "only" that. I'll give a try on that, as soon as I get back on it..

veegee commented 9 years ago

I wanted to rework the connection mechanism. The best way is actually having a separate thread manage the connection itself and poll it for data. The main thread can use queues to communicate with the connection thread, etc.

For now though, RabbitMQ is extremely reliable, so we don't need to really check for heartbeats from the server.

gst commented 9 years ago

For now though, RabbitMQ is extremely reliable, so we don't need to really check for heartbeats from the server.

FYI: this is not mainly for being sure that the RabbitMQ is still Up but to make sure that any FW/network element in the path from the client to the server won't drop the connection due to inactivity timeout..