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 <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
