A danger in relying on a single endpoint is that it's a single point of failure. If you could rely on configuration mgmt to allow the list of mongrel2 servers to be synced across all actors that could alleviate that concern.
-- Patrick Collins On Sep 7, 2013, at 10:14 AM, Maxime <[email protected]> wrote: > Right, that design would work fine with one or a few mongrel2 servers, it's > when I get to 20 servers, ideally I'd like my Actors to publish the response > to a single endpoint (like a xpub/xsub device) so that I can centralize the > management of the list of mongrel2 servers (vs having all response Actors > knowing which mongrel2 servers are out there). And that's where the bind > becomes an issue, let's say I do have a xsub/xpub device that all mongrel2 > servers know about and all response Actors know about, how do I get my device > to talk with the servers if all the servers do their own bind (vs the servers > connect-ing to the device)... > > Maybe I should draw it out to help visualize. :-) > > On Saturday, September 7, 2013, Brian McQueen wrote: >> That's an interesting design. I think it ought to work too by having the >> python actors publish to the SUB queues on the originating mongrel2 host and >> the actors would use the send_ident provided by the originating mongrel2 >> handler spec for the request. They'd also have to talk to that originating >> host's queue using the mongrel2 protocol, as if they were a mongrel2 >> handler. The protocol is very simple, so that should be easy to setup. I >> don't see how the BIND mode would mess it up, but I haven't studied that. >> >> >> On Sat, Sep 7, 2013 at 6:07 AM, Maxime <[email protected]> wrote: >>> Hello, I've tried reading as much as I can about this but couldn't find >>> quite the answer to my question in docs. >>> >>> My plan is to use a multiple mongrel2 servers pointing to a cluster of >>> handlers written in python by me (they are very simple endpoints), which >>> will then forward the requests into a cloud of python actors for processing >>> via zmq PUSH sockets (so it's a pipeline, not a req/rep), the response >>> needs to be eventually sent back to the right mongrel2 server for response. >>> The messages as they transit through the cloud will keep the original >>> envelope parameters required to be sent back to the correct mongrel2 server. >>> >>> The problem I am seeing is that the Mongrel2 servers' response endpoint is >>> a SUB (that's fine) in BIND mode. If it was in CONNECT mode I would simply >>> point all the connection strings towards a XSUB/XPUB device to do the >>> many-to-many PUB SUB between the Mongrel2 servers and handlers. The only >>> thing I could think of but could not find an example anywhere is that I can >>> indeed do multiple "connect_out" calls on the zmq device, once for each >>> Mongrel2 server. All the examples of device I see do a single bind_in and >>> bind_out call (or connect_), never more than one. >>> >>> Maybe I am missing something, maybe it's a zmq question really, but I'd >>> like to see some sample backend architectures to be used with Mongrel2 >>> handlers. >>> >>> Any comments, thought? >>> >>> Thanks >> >> >> >> -- >> the news wire of the 21st century - twitchy.com
