[
https://issues.apache.org/activemq/browse/SM-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46220#action_46220
]
Freeman Fang commented on SM-1571:
----------------------------------
Hi Ron,
After going through the new JMS transport code in cxf, I found that the
JMSConduit actually still use the sync way which means the thread will block
until the respnse back, see the code in JMSConduit.sendExchange()
/**
* If the message is not oneWay we will expect to receive a reply on
the listener. To receive this
* reply we add the correlationId and an empty CXF Message to the
correlationMap. The listener will
* fill to Message and notify this thread
*/
if (!exchange.isOneWay()) {
synchronized (inMessage) {
try {
inMessage.wait(jmsTemplate.getReceiveTimeout());
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
correlationMap.remove(correlationId);
if (inMessage.getContent(InputStream.class) == null) {
throw new RuntimeException("Timeout receiving message with
correlationId "
+ correlationId);
}
}
exchange.setInMessage(inMessage);
if (incomingObserver != null) {
incomingObserver.onMessage(inMessage);
}
}
So this refactor IMHO not enough to solve the thread block issue.
I add comment for CXF-1832
> CXF BC Provider using JMS Transport is not scalable (locks thread waiting for
> external service response)
> --------------------------------------------------------------------------------------------------------
>
> Key: SM-1571
> URL: https://issues.apache.org/activemq/browse/SM-1571
> Project: ServiceMix
> Issue Type: Improvement
> Affects Versions: 3.2.2
> Reporter: Ron Gavlin
>
> The CXF BC Provider using JMS Transport is not scalable (locks thread waiting
> for external service response). Instead, it should be enhanced to behave like
> the SMX-JMS Provider which does not have this limitation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
