Timing out a req/rep socket

[nathasm]

It looks as though sndtimeo and rcvtimeo socket options are not supported. Is this correct? Or if it does, is there an example of how to set these options properly? What I have tried below doesn't seem to work.

var req = zmq.socket('req');
req.setsockopt(zmq.RCVTIMEO, 1000);
req.setsockopt(zmq.SNDTIMEO, 1000);
var sock = req.connect(endpoint);
sock.send(message);
sock.on('message', ...);
sock.on('error', ...);
sock.on('timeout', ...);

If the endpoint isn't up, I wait indefinitely.

[stowns]

Also trying to find a solution to this issue... perhaps something similar to what was suggested for the python lib https://github.com/zeromq/pyzmq/issues/132

[kkoopa]

That is not how the options are called, so it is evident that it will not work. The options are called ZMQ_RCVTIMEO and ZMQ_SNDTIMEO.

[nathasm]

I also tried the ZMQ_SNDTIMEO and ZMQ_RCVTIMEO options, I also set the ZMQ_LINGER, but to no avail.

[stowns]

the options may be working at the zmq binding level but from what I can see the _flush method in the lib will only emit 'error' messages if there is an exception raised.

[kkoopa]

It is supposed to emit an error on timeout. Problem seems to be that zmq_send and other operations should be blocking and have this behavior unless specified otherwise with a flag. For some reasone they seem not to block in zeromq.node, even though the flag is not set. I wonder if it could be the poller that is confusing it, because it works with libzmq.

[lindem]

Sorry to ask, but is there any workaround for this?

[andreyvital]

Same problem here guys... there's a workaround?

[kkoopa]

No workaraound that I know of. Node.js does not like blocking operations, so everything in zeromq.node is non-blocking. These operations will always return instantly, putting messages on the queue for actual sending whenever possible. If there was some way of deleting queued messages, it might be possible to start a timeout and cancel it upon success and let it run and delete the message and raise an error on timeout.

[hems]

So per say, the only work around so far is to create a timeout on our side, and close the previous connection once the timeout happens, right?

I have implemented this simple timeout on waterfront - which i use to interface with zmq https://github.com/nowhereapp/waterfront/blob/master/lib/connect.js#L90-L118

definitely feels like zeromq should be doing the job, not node.js

:v:

[yamsellem]

Any progress on this concern?

[hems]

@yamsellem my solution isn't perfect, but it will retry to execute req again... have a look.

[GMolini]

What was your solution? The link doesnt work

[hems]

@gumlym sorry man, it's been 1 year now. already dropped zeromq and waterfront. my solution now is totally based on redis and i couldn't be more happy.

[GMolini]

Ok never mind. I am using a workaround that just sets a a timeout whenever i send a message with nodejs (with the req socket), then if i havent received anything i just reset the socket (by closing it and opening it again), so that even if the message is produced after the timeout zeromq discards that message.