Hi Freeman, I am less interested in async capability and more interested in scalability. Having threads block while waiting for an external service invocation is not scalable from my perspective.
Let me provide some more context. I am using a smx-cxf-bc provider with jms transport as the transformer for an asynchronous smx-eip pipeline. The pipeline sends an asynchronous, IN-OUT messageExchange to the smx-cxf-bc provider. I expect the smx-cxf-bc provider to behave like the smx-jms provider behaves. It should send the JMS request on one thread and store the messageExchange in an in-memory map keyed by correlationId. A a pool of threads should be listening on the temporary reply-to queue. When the JMS response is received, the receiving thread would find the original messageExchange in the map and return the ME to the pipeline. >From my perspective, it is very important that smx bc providers support async in-out MEPs in this way. I believe both smx-http and smx-jms provide this support. It sounds like the smx-cxf-bc currently does not. Am I correct? If so, what is the best way to address this deficiency? - Ron Freeman Fang wrote: > > 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 >> > > > -- View this message in context: http://www.nabble.com/Does-SMX-CXF-BC-provider-w-JMS-transport-block-thread-waiting-for-a-reply--tp19102173p19107135.html Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
