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 ?
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
