Blocking on incoming message

[gtoonstra]

I'm using nanomsg in a node.js app and had to insert a rcvtimeout option to deal with a blocking operation in nanomsg that was causing all of nodejs to become unresponsive:

``var subscriber = nano.socket('sub');
subscriber.rcvtimeo(50);

subscriber.connect( "tcp://127.0.0.1:5556" )
subscriber.on('message', function(data) {} )``

It's using socket.io and all browsers saw a "stalled" socket.io library download. Interestingly, when the debug console running nodejs was resized, it all became alive again.

With the receive timeout the issue no longer appears.

In this case, the issue only appeared when node was already running and the server with the bound pub socket would come up later. If node was killed, socket.io failed and the browsers could load. If node is brought back up, it works for the remainder of the session. So it's something related to initializing the sub socket when the pub is not there and then bringing the pub up later.

[reqshark]

that's interesting, what kind of machine are you running?

[gtoonstra]

mac osx , python 2.7 stock with python. I believe we built the nanomsg library from 0.5 and then just did an npm install of the latest npm library. I can check tomorrow if you want to be sure.

So the use case is:

• we have a django server that serves web pages
• the same django server can emit events from other sources.
• in the index page, it loads socket.io from the nodejs server and establishes a connction
• the index page hangs.

In the app.js, it allows connections from browser clients (which in this case do not seem to arrive). The app.js attempts to reconnect to django, then it hangs.

What makes this not so consistent is the console resize. So I had nodejs running in the console and when it's resized, messages start flowing again.

Not sure how the nodejs event loop is managed, but it probably doesn't call recv all the time, because it would block the main event loop, so it probably uses polling. Some spurious read event could then cause this loop to hang up pretty easily. That's a hypothesis to investigate anyway.

[nickdesaulniers]

when the debug console running nodejs was resized, it all became alive again.
I had nodejs running in the console and when it's resized, messages start flowing again.

This makes no sense; unless a tty sends some form of signal to a running process on resize. I don't see how the two could even remotely be related. 🚔 🚷

[reqshark]

ditto.

btw to clarify the dep versioning issue:

we built the nanomsg library from 0.5 and then just did an npm install of the latest npm library

as long as you have node 0.10 or later, or io.js, then doing npm install builds from a patched (slightly improved) version of the beta-5 release. that version gets baked into the binding automatically so having libnanomsg on your system is not a requirement.

[gtoonstra]

I totally agree, I did that check a couple of times to reverify.

• When doing nothing, the process hangs indefinitely. Refreshing the page does not help.
• When nodejs is stopped, the page is loaded.
• When the console that nodejs is running on is resized, the page continues too.

Note: with "messages start flowing again" I meant the messages over socket.io, not nanomsg.

In the check there were no external factors that could have interfered like other users or activity from other inputs.

This behavior is strange and I'm not sure if it's worth investigating further as I already have a reliable way to deal with it. It's good to keep it as history that it's been observed.

so important: It only occurs when nodejs connects to django for the first time.

In other sequences of starting up node and the other service, messages are received over both socket.io and nanomsg correctly.

If I get the time this week, I'll try to replicate it.