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.<div>

Java has JEE; erlang has hot code loading; x has y; what does Twisted have? pb?</div><div>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&#39;s designed to be better than).</div>

<div><br></div><div>So my questions:</div><div>1) I&#39;m right, right? Twisted doesn&#39;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)</div>

<div>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?</div><div><br></div><div>Looking forward to your thoughts</div>

<div>Brad</div>