[zeromq-dev] XREQ socket sends messages to death server. How to notice and disconnect from a death server?

MinRK benjaminrk at gmail.com
Thu Dec 9 20:00:29 CET 2010


Hello,

I don't think this is a pyzmq issue, as you posted on GitHub, since it
doesn't behave differently than the same pattern in C.

Here's my understanding:

Since ZMQ is all about asynchronous events, it assumes that a connect() is a
valid connection; the peer just may not be ready yet. Each of the sends that
you made to unconnected peers didn't vanish into the aether, they succeeded,
but are just waiting for the other side of the connection to finish.  In
fact, if you start servers on the extra ports after the loop is complete,
they will indeed receive the messages and send replies back.

In fact, you may notice that the client hangs, and doesn't exit when you
have less servers than connections on the client.  This is because in zeromq
2.1, close() waits for outgoing messages to finish.  If you stop your
initial server, and start others on the unconnected ports, then those
messages will finish sending, and the client will be able to exit.

Where you get stretchy load-balancing on XREQ is with bind(), since that
maintains a growing/shrinking list of peers.

Summary of Load-Balancing with XREQ:

    each connect() gives you exactly one destination (always used)
    each bind() gives you zero-to-many destinations (only connected peers
used)

Toni - I hope that helps
ZeroMQ folks - I hope that was accurate

-MinRK

On Thu, Dec 9, 2010 at 04:07, Toni Michel <michel at snaptec.de> wrote:

>  On 09.12.2010 10:17, Sven Koebnick wrote:
>
> I have a XREQ socket at the client, talking to a set of servers(XREP).
> I want to handle server deaths. The client should notice this, as he
> does not get an answer for a sent request in an
> appropriate time. In this case, the client should resend the message. As
> he is connected to more than 1 server,
> the request will be accomplished by a server which is still available.
> => I cant use blocking recv at the client, as otherwise the client will
> block once he sent a message to a death server
> => instead, the recv must use zmq.NOBLOCK. Each time the client sends a
> message, he waits for 2 seconds max for a reply.
> In case he does not get any, he will resend the message.
> The client sends a message to a death server. As he does not get any
> reply for 2 seconds, he resends the message. As the
> XREQ is loadbalancing, the message is sent to another server, and
> everythings fine. But the problem is, that one of the
> next messages will be send to the death server again. Consider having
> one client and 3 servers. If one server dies, the
> client is sending a msg to the death server every 3 messages
> (loadbalancing).
> => So every 3 messages the client waits for another 2 seconds. Having a
> Gui behind, this behavior is unacceptable.
>
> I thought ZMQ will notice server deaths and remove kill the connection to
> such servers automatically.
>
> Here you can find the complete Testcase: https://gist.github.com/734071
>
> I am starting the client first, connecting to the 3 server adresses. Then I
> start one server, which actually binds to its address.
> The client tries to send the messages load-balanced to all 3 servers,
> although only one has performed a bind. So the client runs
> in the timeout and tries to resend the message to another server.
>
> So the main question are:
> - Am I misunderstanding something?
> - Do I have to disconnect the client from death servers by manually? I
> thought zmq would handle it?
>
>
> Thanks for your help.
> - Toni
>
>
>
> Hm, I spoke with some people at the zmq IRC, and it seems as if it would be
> a zmq bug. I posted an issue here
> https://github.com/zeromq/pyzmq/issues/issue/51
> Maybe youll could take a look twice. I also append a minimal testcase.
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101209/b666f36a/attachment.htm>


More information about the zeromq-dev mailing list