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]<javascript:_e({}, > 'cvml', '[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 >
