[
https://issues.apache.org/jira/browse/CXF-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642450#action_12642450
]
Freeman Fang commented on CXF-1835:
-----------------------------------
Hi Sergey,
It should be CXF runtime -> SMX BC. Basically, smx bc are sets of cxf
interceptors. It receive the request from cxf transport.
After recieve soap messge from the cxf http/jms transport, serveral
interceptor (also cxf concept interceptor) exist in smx code base transform the
soap message to jbi message, and then we have a JbiInvokerInterceptor, which
not really do some invocation, but just send the jbi message to the NMR
(servicemix Normalized message router). the import code is here
if (CxfBcConsumer.this.isSynchronous()
&& !CxfBcConsumer.this.isOneway) {
context.getDeliveryChannel().sendSync(exchange,
timeout);
process(exchange);
} else {
synchronized
(CxfBcConsumer.this.messages.get(exchange.getExchangeId())) {
context.getDeliveryChannel().send(exchange);
CxfBcConsumer.this.messages.get(exchange.getExchangeId()).wait(timeout);
}
}
So you can see if its asynchronous way, we use
context.getDeliveryChannel().send(exchange); this is a nonblock invocation, but
after that, currently we have to block here until we get response from the NMR,
otherwise the Interceptor chain will return without get correct response. What
we actully want is we can suspend the interceptorchain during waiting response
from NMR, and resume the interceptorchain gracefully when the response is
arriving. For http transport, the jetty continuation may be a choice, similiar
issue should be taken into account when use jms transport.
Thanks
Freeman
> 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.
