[
https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642361#action_12642361
]
Daniel Kulp commented on CXF-1835:
----------------------------------
THAT all said, here is something I wrote to Sergey the other day about this:
First, I'd like to know when and how the continuation would be triggered.
I'm assuming this is something that would be done inside the server skel or
similar, right? Basically, their code would start some long running thing
(like maybe make a async call to another service) and then wants to
call "suspend" to create the continuation thing, right?
What would happen currently is the suspend causes the exception to be thrown.
In CXF, that would get wrapped in a fault, sent up to the
PhaseInterceptorChain where it's caught, and then the fault chain started and
a soap fault returned. Obviously not what is wanted here. Thus, something
would need to be done to allow the "suspend" exception thing to propogate up,
but without taking a jetty dependency into the core.
Now, if the above can be figured out, the next problem arises: when
the "trigger" to wake up the continuation occurs (like the async response
comes in), the destination is then called again. Currently, that would
setup a new chain, create a new message, re-call the invoke, etc... Since
the input stream would have been consumed already, that really won't work.
Basically, as part of the creating the continuation, we would need to "pause"
the PhaseInterceptorChain and save the message/exchange. On resume, we need
to make sure we use the same PIC/message/exchange and kind of pick up where
we left off. That's actually not easy either. In this case, the
interceptor that would have been currently executing is the
ServiceInvokerInterceptor which would be calling the Invoker instance. All
of those invoker types would need to be updated to handle the "resume" case.
The JAX-WS invokers are the really tricky ones as they store stuff on the
stack. Those would be lost on the exception.
Basically, to do this "right", we'd need to audit pretty much everything to
make sure nothing is stored on the stack and is "resumable". Once that is
done, the rest is relatively easy. We can add a listener to the
PhaseInterceptorChain that would get notified when pause/resume is called.
In the user code, they would just get the PIC and cause "pause" on it and
either return or throw and exception or something. (likely just return null)
The HTTP transport, when the chain returns, would check if the chain
was "paused" or "complete". If "paused", it would register a the listener
and then do the suspend thing. When the user wants the resume, they would
call resume on the PIC which would trigger the listener which would then call
the resume on the jetty continuation. The JMS transport and such could
also be updated to do something smart in the same situation.
The main amount of work is in auditing the entire code path and interceptors
for stack variables that would need to move into being stored on the message.
We could easily have a "Message.RESUMED" flag on the message so they could
determine that later, but they would need to make sure any data they would
need later is stored on the message and then queryied from there.
> Use Jetty Continuations to implement asynchronous HTTP processing
> -----------------------------------------------------------------
>
> Key: CXF-1835
> URL: https://issues.apache.org/jira/browse/CXF-1835
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.0.8, 2.1.2
> Reporter: Ron Gavlin
>
> Current CXF http jetty transport supports injecting a blocking and noblocking
> connector into the JettyEngine and the default connector is noblocking.
> But we don't use the Continuation to implement the async http processing.
> This is a request to use Jetty Continuations to implement this functionality.
> See
> https://issues.apache.org/activemq/browse/SM-1592?focusedCommentId=46039#action_46039
> for feedback by Willem Jiang.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
