ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maciej Szefler" <...@intalio.com>
Subject Re: Timeout on invoke task: Ode on ServiceMix
Date Thu, 21 Jun 2007 19:38:17 GMT
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 <boisvert@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 <mbs@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 <mike.horwitz@gmail.com> wrote:
> > > Thanks Alex - I will give it some thought.
> > >
> > >
> > > On 6/21/07, Alex Boisvert <boisvert@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 <mike.horwitz@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
> > > > >
> > > >
> > >
> >
>

Mime
View raw message