[zeromq-dev] Advice how to implement QoS for ROUTER-ROUTER or ROUTER-DEALER devices.
Matt Connolly
matt.connolly at me.com
Wed Sep 25 12:17:20 CEST 2013
Hi Artem,
Your first case sounds like the lbbroker example. Why is it that you do not know which worker to send the message to?
With your second scenario, reaching a HWM on the dealer socket would mean that you don’t have enough workers to keep up with the messages coming from the clients. If this is the case, isn’t the answer more workers?
In either case can’t you monitor the scenario by knowing how many messages you have received and how many replies you have sent back?
Regards,
Matt
On 25 Sep 2013, at 12:15 am, Artem Vysochyn <artem.vysochyn at gmail.com> wrote:
> I'm working on creating top-notch rpc-framework (further RPCF) on the base of jzmq/zmq and faced with serious design issue. Here's the deal, in my RPCF I'm going to use devices, especially LRU-device (via ROUTER-ROUTER mechanism), and more trivial FAIR-device (via ROUTER-DEALER mechanism). Regardless of *-device I inevitably will face the challenge of addressing some variant of QoS, here's how:
>
> 1. ROUTER-ROUTER (LRU-device)
> -- remote_client sends request - a message via DEALER
> -- request comes to LRU-device: poller.pollin(int) == true
> -- now we consume a message from frontend ROUTER, and want to pass it further via backend ROUTER, ... but we can't because identity_storage doesn't host suitable identity.
> ** now we got a problem: we consumed message from socket but couldn't forward it further. Also we can't drop message because client expecting reply. So what to do?
>
> 2. ROUTER-DEALER (FAIR-device)
> -- remote_client sends request - a message via DEALER
> -- request comes to FAIR-device: poller.pollin(int) == true
> -- now we consume a message from frontend ROUTER, and want to pass it further via backend DEALER, ... but we can't because HWM is reached, so I get exception, catch it, and now what?
> ** now we got a problem: consumed message from frontend, but couldn't forward it further.
> Also we can't drop message because client expecting reply. So what to do?
>
> As you see, there's two main issues: what to do with a message which has been consumed from socket but wan't passed further because of some condition (in LRU case -- we failed to find suitable identity, for FAIR case -- HWM is reached on backend).
>
> Now, I'm here and asking for your advice regarding what to do with a message?
>
> So far, I implemented mechanism which sends message back to its original sender with RETRY_CALL flag, and if receive_timeout wasn't being exceeded then client sends message again. But is this way to go? Maybe there're some other approaches which I don't see?
>
>
> As usual, appreciate for the help in advance,
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list