[zeromq-dev] zmq_socket_monitor blocks port of REP/REQ TCP/IP in C

[Björn Kuhlbrodt]

Hi Goswin

>> Hmm, too bad. As I said, socket_monitor is working fine (although not 
>> perfect maybe) in our application. It just does not close without 
>> messing up the context.
>
>In what way does it mess up the context? Please open an issue in the bug tracker.

Both TCP socket and monitor sockets are disconnected and unbound (successfully), both sockets are closed (successfully) but the final ctx_term throws an exception (access violation). I'll try to run with debug binaries to get some more information about where the exception comes from. 

If I don't close the context, I can't bind the port again, even though the _unbind and _close were successful.

>
>> And if it's not good for watching the connection and messes up the 
>> context, how about a little warning in the doc: devolopers tool, 
>> instable, beta, ....? It took us _some_ time to isolate socket_monitor 
>> as the culprit.
>
>He didn't say it was no good. He said that not all problems will cause a disconnect to show up on the monitor socket. Simplest >example: The peer goes into an endless loop and doesn't respond/send messages anymore. The socket will be kept alive by the kernel >so you won't get a disconnect. A heartbeat though will tell you that the peer is unresponsive.

Yes, I understand that and we've covered that. The rest, client goes offline (power loss, program crashed, etc), we've been covering with socket_monitor. Which works fine and covered all our test-cases. We just can't close and reopen our communication properly anymore without killing the entire application, which unfortunately is a requirement. 

That said, I'll have to implement a heartbeat, but still will try to drill into the socket_monitor problem and file an bug report if I can assemble any helpful information. But as said in an other mail, I'm moving in a million lines of closed-source code with proprietary classes for about everything. Which makes test cases and even reproducible errors hard and time-consuming. I'll try tough. 

Best regards
Björn