Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/ipython/ipython/issues/1304/ below:

controller/server load can disrupt heartbeat · Issue #1304 · ipython/ipython · GitHub

For code that uses ZMQStreams for heartbeat (notebook, hub), it is actually possible for server load to disrupt the heartbeat. I'm not sure if this actually happens, but it is a real possibility. I expect the most likely case is the Hub, which can have very long blocking calls when using the mongodb/sqlite task stores.

The relevant aspects of the code:

• stream.send(msg) does not actually send a message, it registers a message for sending, which will happen at the top of the next loop iteration at the earliest.
• server load can make this loop iteration take an abitrarily long time, inserting a potentially long delay between stream.send(msg) and socket.send(msg).
• heartbeat timer starts simultaneously with stream.send(), not socket.send(), so the above delay is interpreted as a delay in the heartbeat response, and can be longer than the total heartbeat period, causing a heart failure.

Possible solutions:

1. ZMQStreams have an 'on_send' method for registering callbacks for when the actual Socket sends the message. If we schedule the next heartbeat relative to that, rather than as a PeriodicCallback with stream.send then the heartbeat measure would be accurate.
2. call stream.flush() immediately after stream.send(), which will cause the socket to send the message, if possible (it will never be impossible with our current patterns).
3. directly call stream.socket.send(), bypassing the issue entirely.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4