On Sat, Aug 20, 2011 at 10:49 PM, Mathijs Kwik <[email protected]> wrote:
> However, in the LRU example, routing/load balancing is lifted from > zeromq into the application itself. Yes, that's right. > Basically you end up replicating big parts of functionality that > normally get provided "behind the scenes" in push/pull sockets, just > because there's no way to close a socket without losing data. Push/pull sockets do not provide this functionality at all, which is why we do build it on top, if we want it at all. > Application code doesn't hear about the reconnection, > forcing the use of (arbitrary) timeouts and cleaning up yourself in > the application. Indeed. This is being improved in 4.x, to make ROUTER sockets more useful. However it's not a major issue since worker failure is presumably rare. You just need to detect it, recovery can entail resubmitting the entire job. Your original question was about custom routing so that some workers could be left idle. > Writing all that routing/problem detection/message tracking code seems > to take the usefulness (and fun) out of zeromq. ZeroMQ doesn't try to do everything, that's a large part of its fun and usefulness. > If the application has to provide all those things by itself, I think > it can just as easily be applied to plain tcp/unix sockets (maybe add > some framing code then). Well, you would have to do exactly as much work to handle routing and errors, but additionally you'd need to do pretty much everything else 0MQ does. There's a reason even the more complex (and realistic) examples in the Guide are still a few hundred lines of code. I'd certainly encourage you to try plain TCP sockets. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
