Hi Guenter,
Thanks for the reply. Our problem here is that we don't control the
services (this system integrates whatever it finds, that's the point)
and that when I call call.invoke(...) it blocks until there's a response.
What I'd ideally need is something that allowed me to specify a callback
of some kind to call.invoke and have the initial method call return
immediately. This would then have to be combined with some agent that
received _all_ soap messages (otherwise you just have another thread
listening per service and it defeats the point) and invoked the callback
when a message arrived that was in some way correlated to the initial
request.
I have a suspicion I'm moving into 'write your own soap toolkit'
territory again...
Tom
Grossberger, Guenter wrote:
Hi, Tom!
First I don't know if something like that is covered in Axis 2.
But I guess the Half-Sync/Half-Async pattern or an other event-handling
or concurrency pattern described in the POSA2 book (Pattern-Oriented
Software Architecture: Patterns for Concurrent and Networked Objects
Vol. 2, http://www.cs.wustl.edu/~schmidt/POSA/) would work for you.
Bye,
Guenter
-----Original Message-----
From: Tom Oinn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 08, 2005 2:19 PM
To: [email protected]
Subject: Minimising thread usage across multiple axis calls
Hi all,
Consider this problem - we have a set of services outside of
our control
(a mixture of doc/lit and rpc, that's not important though) which are
being orchestrated into a dataflow style workflow. At present we must
allocate one thread to each service invocation and this is
potentially a
problem for cases where either a single workflow launches
thousands of
services concurrently or where the workflow service itself is
hosting a
large number of active workflows.
In principle it would seem possible to have a thread which
was aware of
all currently pending SOAP operations (where the request message had
been sent but no response received) and which could poll some
incoming
queue regularly, launching any neccessary threads if messages
are present.
This implies a client manager component, I'm not aware of anything
analogous to this in the current architecture though?
Questions :
1) Is this covered in the Axis2 design in any way?
2) Is anyone else interested?
Cheers,
Tom
