cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: Jetty Continuations in CXF
Date Wed, 12 Nov 2008 13:16:41 GMT
Agreed. Especially if continuations can be supported somehow on the
JMS transport, ServiceMix should not depend on the jetty internal

On Wed, Nov 12, 2008 at 1:08 PM, Freeman Fang <> wrote:
> Sergey Beryozkin wrote:
>>>> So before a suspended runtime exception reaches the nearest catch block
>>>> in
>>>> the CXF code where we can get a chance to do something to preserve the
>>>> state
>>>> of the given invocation, resume() might've alreadty occurred.
>>> That's why you need some synchronization blocks to ensure resume can
>>> not be called before suspend has been handled somehow.
>>> I would suggest wrapping the jetty continuation into something more
>>> CXF specific which could be used for other transports too.
>> Yes, I think we're on the same page here. Case 2 is exactly about the user
>> code interacting with the
>> (jetty - when http is involved) continuations indirectly. But I think we
>> agree that if a user code does suspend on an underlying jetty continuation
>> object directly then a race condition leading to a 'loss' of message might
>> occur if resume() is done in parallel, virtually immediately after suspend()
>> was called.
>> Question : how will SMX CXF Binding Component interact with (Jetty)
>> continuations when dealing with CXF-originated invocations ? The
>> Continuation wrappers will be available through an internal CXF input
>> Message and through JAXWS WebServiceContext (or JAXRS one later on) - will
>> CXF BC be able to get hold of such wrappers  ? If yes then I guess we have
>> no problems at all ?
> Yes, I think so, get continuation from cxf message
> (org.apache.cxf.message.Message) is fine for CxfBcConsumer.
>>> Whoever calls the suspend() does not really matter here.
>>> The problem is that suspending the continuation will trigger a timer in
>>> jetty.
>>> When this timer elapse, the request will be replayed with a flag on
>>> the continuation
>>> saying it has been timed out somehow (we check the cont.isPending()
>>> flag in smx).
>>> At this point, you need to ensure that the timeout will be handled
>>> correctly both on the
>>> http response side, and on the cxf message side.
>> I'm feeling silly :-) as I don't get it.
>> Input :
>> 1. What CXF JettyDestination can do if it finds out that a continuation
>> with say 'resumed' status, which is what I see in case1 as I described
>> earlier has no message associated with it ?
>> 2. Why it should care about the suspended/resumed status of the
>> continuation when its *isNew()* call returns *false* ?
>> If it has a message attached to it then what difference would it make for
>> the resumed invocation whether this invocation has been resumed due to that
>> continuation being resumed explicitly or timed out ? I honestly see no
>> difference
>> Output :
>> I don't so anything at all on the Jetty Destination output, as far as
>> continuations are concerned. Some code down the line calls cont.resume() or
>> this continuation expired, in both cases the request is retried by Jetty
>> (that's the inbound path). If the existing message is found on the incoming
>> http request's continuatiuon - we resume a paused invocation otherwise we
>> start a new one. As I said - we might throw an exception at this point if we
>> find that the not-new continuation has no message attached to it - logging a
>> warning for now.
>> Either way, eventually this invocation returns. Why should we do anything
>> about the fact at this stage that this invocation was 'resumed' by the timer
>> expiring ?
>> Am I totally slow ?
>> Cheers, Sergey

Guillaume Nodet
Open Source SOA

View raw message