cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
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
continuations.

On Wed, Nov 12, 2008 at 1:08 PM, Freeman Fang <freeman.fang@gmail.com> 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
>>
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message