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
