Hello,
I want to integrate suds into async framework, in my case twisted. So I looking for the best way to do this. Has anyone done such a thing before ?
I don't see an easy way to implement callback handling into suds, so the preferably way seems to directly use the transport mechanism from the framework instead.
For doing so I only need the pure payload (a instance of Request seems to have anything I need). For the transport I use the twisted modules. The result should of course be fed back into suds to get out the nice suds objects.
So to be specific: - How can I get the Request instance that normally would be given over to the Transport instance ? - How can I get the suds object by supplying the pure response from the remote side ?
Greetings Steffen
Quoting Steffen Oschatz on 01/28/2009 12:23 PM:
Hello,
I want to integrate suds into async framework, in my case twisted. So I looking for the best way to do this. Has anyone done such a thing before ?
I don't see an easy way to implement callback handling into suds, so the preferably way seems to directly use the transport mechanism from the framework instead.
For doing so I only need the pure payload (a instance of Request seems to have anything I need). For the transport I use the twisted modules. The result should of course be fed back into suds to get out the nice suds objects.
So to be specific:
- How can I get the Request instance that normally would be given over
to the Transport instance ?
- How can I get the suds object by supplying the pure response from
the remote side ?
Greetings Steffen
fedora-suds-list mailing list fedora-suds-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-suds-list
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.
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@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.
-
Renato Alves -
Steffen Oschatz