Let us know what you end up doing! -- Patrick Collins
On Sep 7, 2013, at 3:17 PM, Maxime <[email protected]> wrote: > That's a good point, but it felt like the xpub/xsub solution was simply an > extension of the philosophy behind mongrel2's use of sub to avoid > configuration and connection sprawl as well as extended the "add a handler > with no configuration change" with "add a server with no configuration > change". > > Seems like the ability to have a mongrel2 server's recv endpoint do a connect > would be a nice feature to have in the future. > > Thanks for your answers. > > On Saturday, September 7, 2013, Pat Collins wrote: >> 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
