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