Thanks all for the thoughts.<br clear="all"><br>Clinching drivers for us to choose AMQP (RabbitMQ) include built-in persistence, manual ACK (ie only when finished, not just when pulled), plus the obviously strong configuration-driven routing capabilities.<div>
<br></div><div>With this distributed architecture using rabbit, we're not likely to pursue a hot-swap design with Twisted - there wouldn't be the same payback compared with the ease with which new entire adapter service code can be deployed with rabbit maintaining messages between components. It is something I've come back to a few times though - have thought roughly about the idea of an enhanced Service class that can be easily swapped in and out.</div>
<div><br></div><div>The plan was that if we continued with <i>n </i>Twisted services attached by rabbit queues that we'd eventually build some manner of central Manager that could be responsible for tracking these things. In fact we may extend it to become a deployment manager as well at some point, that could control the graceful swapping out of Twisted services.</div>
<div><br></div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Introducing these kinds of limits into the Twisted ecosystem would not be impossible, but it is very challenging, because you'd have to come up with a model that applied equally well to all of the supported protocols and all the ways you might want to store state within those protocols.</blockquote>
<div>On this note, I hadn't aimed for the gold-plated approach of persisting every state - we have stateful objects that we pass around and was thinking more of closing all inbound services, waiting for completion, then closing outbound services and persisting these objects' state. That would be less reusable across Twisted as a whole, I understand, but certainly makes for a more easily consumable first bite. </div>
<div><br></div><div>Fair enough re 'best-practice' :) I knew if I went as far as to ask that, I'd get a reasonable gauge back at least</div><div><br></div><div>Thanks again</div><div>Brad</div><div><br></div>
<div>
PS - Christopher, I look forward to seeing that lib</div><div><br><br><div class="gmail_quote">On 21 October 2011 07:13, Glyph <span dir="ltr"><<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Oct 20, 2011, at 6:50 AM, Brad Milne wrote:<br>
<br>
> We have a core message-handling platform which encompasses an ever-increasing array of modules and services run inside one Twisted process. This is good as it means the reactor is in control of most of the stuff relevant to it. However, as the number of deployed services within it grows, it becomes increasingly burdensome to have all the modules in a single deployed codebase running in a single launched process.<br>
> Java has JEE; erlang has hot code loading; x has y; what does Twisted have? pb?<br>
<br>
</div>Erlang can do this because it has a strict separation of state and behavior (in the vernacular, "it is not object-oriented") and J2EE can do this because it requires you to externalize all your state - usually to a relational database. Part of the appeal of Twisted is that you can freely use simple, in-memory mutable data structures to store your mutable state.<br>
<br>
Introducing these kinds of limits into the Twisted ecosystem would not be impossible, but it is very challenging, because you'd have to come up with a model that applied equally well to all of the supported protocols and all the ways you might want to store state within those protocols.<br>
<div class="im"><br>
> To date we have begun introducing RabbitMQ (AMQP), with separate Twisted processes running as adapters at either end of queues. On the surface this fits nicely as it provides distributed architecture, resilience through isolation, and decoupled upgrade paths. On the flipside though, it means more technology and more processes running outside of a singleton Twisted reactor (read: OS process management, which Twisted's designed to be better than).<br>
<br>
</div>I'm not sure what you mean by "OS process management" versus "Twisted process management". It's true that you get some benefits from using spawnProcess to manage your subprocesses, since you can write code to automatically start and stop them in response to certain stimuli, but this relies completely on however it is your OS starts and stops processes. Why not just have a Twisted monitor process that starts and monitors the health of all of your queue producer/consumer processes? Then you should get the best of both worlds.<br>
<div class="im"><br>
> So my questions:<br>
> 1) I'm right, right? Twisted doesn't have mechanisms or a library for hot swapping code modules or similar solutions for low impact upgrades and high availability? (I originally read about Twisted *plugins* hoping for this, but was disappointed to find how basic they actually were)<br>
<br>
</div>Reza already replied with a pretty good list of possible options for this, but: no, there's no single, one-size-fits-all solution for this.<br>
<br>
And there could be! As I said above, it's tricky, but if you could think of a good design for such a system, I'd absolutely LOVE for it to be in Twisted. Please feel free to contribute something :).<br>
<div class="im"><br>
> 2) Is RabbitMQ with txAMQP-empowered Twisted instances on the ends of the queues a sensible, compatible, best-practice approach as agreed by the community?<br>
<br>
</div>No.<br>
<br>
I don't mean that it doesn't work, I just don't like the term "best-practice".<br>
<br>
Maybe your implementation is a good idea, maybe not. But if I said it's a "best practice", that would relieve you of the need to think critically about whether or not this approach was satisfying your requirements. There are some cases where this is a good idea, some not. There are some people in the community who have had good experiences with this approach; I personally don't use it.<br>
<br>
You'll have to be the judge of whether it's working for you or not.<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br></div></div>