zmq_disconnect() and zmq_unbind() are aliases to eachother ^) >> Also, for unbind() should this just >> stop the listening of new connections already patched >>but leave existing connections intact? I believe that the proper behavior is to terminate them with LINGER value(the same as in zmq_term()) Unfortunately this is not happen and here is my description of second bug ^) now for unbind():
PULL->bind() socket doesn’t disconnect all connected sessions after zmq_unbind() and ZMQ_LINGER expired. (tcp_listener_t and all owned base_session_t(connect=false) actually terminated only at zmq_term() althrough tcp_listener_t processes TERM command and propagates it to all owned base_session_t, but then the terminate process stops(even after LINGER timer event)... I believe it stops somewhere in pipe_t::process_term()) Example code: a. Server: http://pastebin.com/bUvcguCK b. Client: http://pastebin.com/yPxsbf83 c. Run server, server will block in zmq_send(). d. Run client. e. Run ‘netstat –anp | grep 5560’ to ensure that you have 3 TCP sockets(one listening and two for bidirectional connection): root@ast-pbx-spb-1:~# netstat -anp | grep 5560 tcp 0 0 127.0.0.1:5560 0.0.0.0:* LISTEN 12913/push tcp 0 0 127.0.0.1:5560 127.0.0.1:60814 ESTABLISHED 12913/push tcp 0 0 127.0.0.1:60814 127.0.0.1:5560 ESTABLISHED 12934/pull f. Wait for 10 packets and zmq_unbind() and sleep() forever g. Run again ‘netstat –anp | grep 5560’ to ensure that you still have 2 bidirectional TCP sockets, so sessions will not be disconnected. server is blocked again in zmq_send() – which is good client will wait forever in dead PUSH connection since it never closed. ________________________________ От: [email protected] [[email protected]] от имени Neale Ferguson [[email protected]] Отправлено: 25 апреля 2012 г. 21:21 To: ZeroMQ development list Тема: Re: [zeromq-dev] s390x build failure <naïve> When zmq_unbind() completes, can’t an indicator be set in the structure representing the structure such that subsequent I/O causing APIs will check this and not go further down the stack to try and complete the call? Similarly, couldn’t zmq_disconnect() do the same? Also, for unbind() should this just stop the listening of new connections but leave existing connections intact? Judging by the way’s it’s being used I assume the answer is no. </naïve> On 4/25/12 12:35 PM, "Sergey Hripchenko" <[email protected]<UrlBlockedError.aspx>> wrote: I was hoping that you have more exotic OS ^) About issue: zmq_sleep (1) should be _enough_ for everything. However, for example I found that: PUSH->connect() PUSH->recv() > 0 PUSH->disconnect() // and this will leave PUSH -> session_base_t -> tcp_connecter_t forever until you call some io functions like PUSH->recv(ZMQ_DONTWAIT)=-1 // the TERM command simply _NOT_ propagaded from session_base_t::process_term_req()(called in application thread) to tcp_connecter_t::process_term()(called in ZMQ IO thread) Not sure if anyone interested in this issue... ________________________________ This message is intended only for the person(s) to which it is addressed and may contain Intermedia.net Inc privileged, confidential and/or proprietary information. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Any disclosure, copying, distribution, or the taking of any action concerning the contents of this message and any attachment(s) by anyone other than the named recipient(s) is strictly prohibited.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
