HI Chuck,
Cheers for that, it's along the lines I was thinking, I guess the FAQ entry
you refer to is the difference of bind vs connect..
So I guess this will happen for every client that connects to the server..
I have changed the test code to be as you suggested, and it does work cleaner
now with a lower timeout, although it was only a test
example, the real one would have one client per process etc ...
Two final questions :
1. What is a reasonable timeout, I've seen 1 second arbitrarily use, I assume
that is ample time unless
client/server are opposite sides of the globe ?
2. Will this always be the case ? or is there support planned for this to be
handled internally to the pattern in time ?
Many thanks for the help,
Brian.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Chuck Remes
Sent: 25 September 2012 16:30
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ROUTER-DEALER missing connects/messages.
On Sep 25, 2012, at 10:05 AM, Dowd, Brian wrote:
> HI Michel,
> Yes it is a multi-part message on the send side, however the first
> part is just the identity/destination/address details (i.e.
> client-1/client-2 etc), and the setIdentity() call in the "Client"
> side of things associates thw two so that when the "client-1" is set
> in the first part the ZMQ layer knows to send that message to the
> "Client" that connected with identity "client-1" .... Also, just in case I
> did double check the rtdealer.c and it behaves exactly equivalently in that
> it does not loop as you suggest, but does it the same way as my java example
> more or less, I imagine looping woudl make sense when you are not using
> ROUTER/DEALER and do not know in advance how many parts there are ...
>
> I dont believe it is the issue here.
I believe your issue is due to a race condition during startup. Simply put,
when the ROUTER socket binds to an endpoint it does not actually create an
outgoing queue *until* a client connects to it. So any messages written to the
ROUTER socket will be dropped at first. Take a look at its behavior as
documented in the zmq_socket man page. This dropping behavior (when there are
no connected clients) may not be clear from that man page, but we do have it in
the FAQ.
http://www.zeromq.org/area:faq
Putting a "sleep" in your server corrects this behavior because it gives the
client threads a chance to start up and actually connect to the bound endpoint.
When the ROUTER socket sees a peer, it creates an outgoing queue for it. Any
subsequent writes to that ROUTER socket can now be placed in the queue (subject
to any HWM limits).
To solve this, I recommend changing your client. Instead of each client thread
creating its own context and socket, your main thread should create a single
context and spawn all of the sockets that you will ever need, connect them, and
then sleep briefly. Pass this connected socket to your thread constructor.
Also, anyone using ROUTER/DEALER sockets should read this write-up:
http://www.zeromq.org/tutorials:dealer-and-router
cr
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
