Actually.... orginally this was a send() operation for this very reason. Someone (cough) changed it to use sendSync instead:
r521390 | boisvert | 2007-03-22 14:11:04 -0400 (Thu, 22 Mar 2007) | 2 lines Use sendSync() rather than send() for better load conditioning I think this was an error, we should be using send(). -mbs On 6/21/07, Michael Horwitz <[EMAIL PROTECTED]> wrote:
Thanks Alex - I will give it some thought. On 6/21/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > Hi Michael, > > We currently use sendSync() mostly because the engine doesn't know better. > We would need to introduce an annotation somewhere to chose between sync > or > async, as well as configure the timeout. (Same issue with the Axis2 > integration layer) > > Any thought on where we should do this? In the WSDL protocol binding? > > In the mean time, the recommendation is to break up your request-response > operations into two one-way operations and use timers in the process as > the > timeout mechanism. The main drawback here is the loss of built-in > fault-handling behavior, although it makes your process more portable > because you're making less assumptions about the transport layer. > > cheers, > alex > > > > On 6/21/07, Michael Horwitz <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > Looking through the ODE Jbi code (and observing the corresponding > > behaviour > > in a running process) I noticed that Ode uses the > DeliverChannel.sendSync > > () > > operation to invole other services on the bus. Is there any support for > > fully asynchronous service invocations in JBI? Or some way to influence > > the > > timeout for longer running processes? > > > > Thanks > > > > Mike Horwitz > > >
