JustinTulloss
Messages stop being received on sub socket after receiving the first few
Here is the code that I use to subscribe to messages
var sockSecDef = zmq.socket('sub');
sockSecDef.on('message', messageHandlers.handleSecdefMessage);
sockSecDef.connect(socketInfo.secdef);
sockSecDef.subscribe('');
This started breaking after this PR: https://github.com/JustinTulloss/zeromq.node/pull/395
hmm, can't reproduce here. after restarting everything, the bind server, the connect machine, etc. are you still able to isolate that commit as the cause?
if yes, then:
- what protocol transports/address types are you using?
- what's the C++ code you mentioned in that PR?
- and, just kinda curious, are you doing stuff with
EINTR?
Yep, I've given everything several restarts with and without the commit and I'm seeing the same issue.
However, this may be due to a misuse of the library. I just saw that someone used the send() method on a SUB socket. Is this valid?
Its a tcp connection to a remote machine The C++ code is pre-existing code that a client already have that I have to integrate with. As far as EINTR goes, I'm just running the code - not trying to interrupt it.
I'll give it a try without the send call and let you know if we can close this.
Getting rid of the call to send does fix the issue. This is a bug in my code, however before that PR went through, it was just ignored and everything continued to function.
Perhaps it would be good to throw an error if send is called on a socket that shouldn't be able to send.
Feel free to close this issue whenever you want
while it's never valid to call send() method on a sub socket, and given the need to protect against this kind of bug in the future, I still think the last thing we want to do is introduce a redundant check for socket type validity during each outbound send operation.
that would impact performance so it would be better to try to make the send() method unavailable.
perhaps we should overwrite the method with a JS undefined on sub and pull sockets, that would automatically throw
I like the idea of setting send to undefined on sub and pull socket, and it neatly sidesteps any performance impact.
Of course, instead of setting the method to undefined, you could set it to a function that would throw an error that has a helpful "don't call send on a sub socket" message in it.
