[Twisted-Python] Twisted enterprise deployment models

Brad Milne brad.milne at devx.runthered.com
Thu Oct 20 04:50:50 MDT 2011


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.
Java has JEE; erlang has hot code loading; x has y; what does Twisted have?
pb?
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).

So my questions:
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)
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?

Looking forward to your thoughts
Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20111020/58c22a08/attachment-0001.html>


More information about the Twisted-Python mailing list