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 <[EMAIL PROTECTED]> 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
