You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Michael Horwitz <mi...@gmail.com> on 2007/06/21 11:57:12 UTC
Timeout on invoke task: Ode on ServiceMix
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
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Maciej Szefler <mb...@intalio.com>.
This is a problem of incomplete implementation. sendSync() can be
implemented with send(), so in it is not only better in theory, but it
/can/ also be better in practice. So given the SEDA nature of
servicemix, it seems more appropriate for the goal to be an
implementation that uses the "native" primitive (send()). That said,
that may cause certain problems, which is why the override capability
is there ;).
-mbs
On 6/21/07, Alex Boisvert <bo...@intalio.com> wrote:
> This is a case where send() is a better idea in theory but in reality it
> causes a few problems. We've witnessed this on a fairly large-scale
> deployment with ServiceMix. Using send() leads to a lot of MEX being held
> in memory and a lot of threads being created and you quickly run out of
> memory. Granted, these are problems of the ServiceMix SEDAFlow
> implementation but that's what I've seen most Ode users use.
>
> I'm all for configurable behavior although I strongly believe sendSync() is
> the better default.
>
> alex
>
>
> On 6/21/07, Maciej Szefler <mb...@intalio.com> wrote:
> >
> > 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 <mi...@gmail.com> wrote:
> > > Thanks Alex - I will give it some thought.
> > >
> > >
> > > On 6/21/07, Alex Boisvert <bo...@intalio.com> 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 <mi...@gmail.com> 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
> > > > >
> > > >
> > >
> >
>
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Alex Boisvert <bo...@intalio.com>.
This is a case where send() is a better idea in theory but in reality it
causes a few problems. We've witnessed this on a fairly large-scale
deployment with ServiceMix. Using send() leads to a lot of MEX being held
in memory and a lot of threads being created and you quickly run out of
memory. Granted, these are problems of the ServiceMix SEDAFlow
implementation but that's what I've seen most Ode users use.
I'm all for configurable behavior although I strongly believe sendSync() is
the better default.
alex
On 6/21/07, Maciej Szefler <mb...@intalio.com> wrote:
>
> 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 <mi...@gmail.com> wrote:
> > Thanks Alex - I will give it some thought.
> >
> >
> > On 6/21/07, Alex Boisvert <bo...@intalio.com> 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 <mi...@gmail.com> 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
> > > >
> > >
> >
>
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Maciej Szefler <mb...@intalio.com>.
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 <mi...@gmail.com> wrote:
> Thanks Alex - I will give it some thought.
>
>
> On 6/21/07, Alex Boisvert <bo...@intalio.com> 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 <mi...@gmail.com> 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
> > >
> >
>
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Michael Horwitz <mi...@gmail.com>.
Thanks Alex - I will give it some thought.
On 6/21/07, Alex Boisvert <bo...@intalio.com> 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 <mi...@gmail.com> 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
> >
>
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Alex Boisvert <bo...@intalio.com>.
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 <mi...@gmail.com> 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
>
Re: Timeout on invoke task: Ode on ServiceMix
Posted by Maciej Szefler <mb...@intalio.com>.
I've implemented a user-selectable property
'org.apache.ode.jbi.sendSynch', if set to true synchronous sends will
be used, otherwise async invocations are used.
Also, you can change the default timeout with the
org.apache.ode.jbi.timeout property. set it to the number of ms. This
works both in sync/async mode.
In the future we will need to allow configuration of this on a partner basis...
On 6/21/07, Michael Horwitz <mi...@gmail.com> 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
>