Yes, I'm aware of the fact, that I need at least 5 dispatcher instances to be able to send messages in 5 recursive levels. that's OK, but it's not the Problem ... anyway, you understood the situation correctly ;o)
I'm afraid, I'l have to implement that part myself ... this was my main argument to use a massage queueing system.
Can you tell me, where I have to start searching (in your code) to temporarily take busy workers out of the balancing ?
rgds
Sven
---------------------------------------------------------
E = mc² ± 2dBA ----- everything is relative
---------------------------------------------------------
-----Original Message-----
Date: Wed, 20 Oct 2010 09:32:12 +0200
Subject: Re: [zeromq-dev] loadbalancing problem?
From: Martin Sustrik <sust...@250bpm.com>
To: Sven Koebnick <sven.koebn...@t-online.de>, ZeroMQ development list <zeromq-dev@lists.zeromq.org>
Hi Sven,
Conclusion: (correct me, if I'm wrong ;o) the balancing algorhythm does a round robin on all CONNECTED workers instead of doing a round robin on currently RECV()ING workers.
Since I'm not that deed in the guts of ZMQ, I'd like to ask: is it very complicated to rewrite the XREQ socket (the worker side in the queue device) to balance the requests only to workers, that are really idle and currently recv()ing?
Actually, it's impossible. When you are sending the message you have no guarantee that the receiver will be still recv()ing when the message arrives.
As for your design, you have a distributed deadlock in your app. You have to fix that. Even if 0MQ was able to send only to sockets that are actually recv()ing at the time, it wouldn't solve your problem.
Imagine there are 5 nested calls of "service" instead of 2 as in your example. First one would block service instance 1, second one would block instance 2 etc. The fifth nested call would deadlock :(
In short, if you want to invoke services in recursive way you have to ensure that the instance when performing a request, doesn't block other requests to happen in the same time.
Mostly, the above is implemented by no state in the service, all state being packed in the messages.
Martin
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
