I also thought about wrapping the whole remote call in a deferToThread,
but of course your solution sounds more powerful.
I would be really thankful if you could provide some snippets.
On Wed, Jan 28, 2009 at 1:49 PM, Renato Alves <rjalves(a)igc.gulbenkian.pt> wrote:
Hi Steffen,
I'm using suds + twisted. I haven't implemented this in an async way
directly on suds but instead using a cached thread pool of suds clients +
queue. It's not the most elegant way but it solves my problem.
Basically when the daemon (twisted) launches it fires up 5 extra threads
each one creating a soap session using suds (caching the wsdl and a session
ticket with the soap server). The threads are partially idle (checking once
in a while the ticket validity) until some request gets queued. Then they do
their thing in a blocking manner (due to some server constraints) and when
they finish they put the result in a global dict. This dict is accessible by
the main thread that runs twisted and a simplified xmlrpc server. With this
approach I can not only skip the performance penalty of starting a new soap
session, authenticate and all that, but also, keep a temporary cache of the
results.
If you think any of this code could be of use to you, give me a call I will
be glad to send you some snippets.