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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
