[zeromq-dev] dealer responsibility with the DEALER->REP pattern

Mikhail Gorbunov mikhail at sirena2000.ru
Mon Apr 30 09:53:22 CEST 2012


 Quote :
> It does sound like you want an LRU queue, or perhaps a more generic
> type of credit-based flow control[1].

> [1] http://unprotocols.org/blog:15

Pieter, Michel, I'm taking the liberty to answer you both in one message.

The credit-based flow control described above seems to be a bit overkill
for me, though I am trying the LRU pattern right now and while it looks
pretty simple and killing all my needs in maybe even less swings than the
DEALER->REP did, it (silently) introduces persistent (durable) sockets.

As far as I have learnt, that by no means is an issue if the application
makes a clean exit, but if a bunch of workers got stuck and cannot operate
anymore, doesn't that mean that the router will still be living in hope
the answers from the fallen will be received one day? Of course, it won't
try to delegate any further workload to them, but I suspect being awaiting
for the answer from such processes leads to hung resources.

My system is by no means a small embedded application and another megabyte
for the good means is almost unnoticeable, but on the other hand a hundred
excessively opened fds is quite unwelcome. From here I can see the only
workaround for this: detecting such a stuck with an external monitor and
restarting the stuff.

With great appreciation,

-- Mikhail



More information about the zeromq-dev mailing list