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

[gst]

…_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]

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]

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]

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]

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]

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..