Hi Ron,
Yes conduit.handleResponse() will block the thread when it waits for the
reply, but it doesn't means you lost async capability.
IMHO, only client request initiator should take care of the sync/async
issue.
In Servicemix, for cxf-bc provider, it's a bridge between message inside
jbi bus and message outside jbi bus, it's not client request initiator,
so cxf-bc shouldn't take care of if the incoming message is asynchronous
or synchronous.
What should take care of aync/sync is the client request initiator, such
as cxf client or servicemix client (as what the customer use "send" for
async, and "sendSync" for sync).
In cxf, we have async cxf client, which create another thread to do the
client request, so even this thread get blocked in handleResponse, the
main client thread will not block, so for an end user of async client
api, everything is asynchronized, you can send several client request in
your main client thread without block.
For camel, if it support some async client api similar as cxf or smx, it
should be fine for your requirement.
Regards
Freeman
rgavlin wrote:
Greetings,
Based on Willem's response in
http://www.nabble.com/forum/ViewPost.jtp?post=19100138&framed=y, it appears
that CXF's JMS transport conduit.handleResponse() will block the thread when
it waits for the reply. Is this indeed the case as well for the SMX-CXF-BC
provider's use of CXF's JMS transport?
If so, should I open a JIRA with CXF and/or SMX-CXF-BC to address this
scalability problem? I believe the new SMX-JMS endpoints use Spring JMS
templates to get around this problem and I think the old SMX-JMS endpoint
used a store/storeFactory. How would it make best sense to address this
issue with CXF/SMX-CXF-BC?
- Ron
