[zeromq-dev] HA: s390x build failure

Sergey Hripchenko shripchenko at intermedia.net
Wed Apr 25 19:35:37 CEST 2012

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 at ast-pbx-spb-1:~# netstat -anp | grep 5560

tcp        0      0*               LISTEN      12913/push

tcp        0      0         ESTABLISHED 12913/push

tcp        0      0          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.

От: zeromq-dev-bounces at lists.zeromq.org [zeromq-dev-bounces at lists.zeromq.org] от имени Neale Ferguson [neale at sinenomine.net]
Отправлено: 25 апреля 2012 г. 21:21
To: ZeroMQ development list
Тема: Re: [zeromq-dev] s390x build failure

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.

On 4/25/12 12:35 PM, "Sergey Hripchenko" <shripchenko at intermedia.net<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->recv() > 0
// 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120425/55193df7/attachment.htm>

More information about the zeromq-dev mailing list