Freeman, This really is a "deficiency" in the CXF API's that should be addressed there, but it would be a pretty big refactor and would probably introduce all kinds of incompatible changes.
In the jaxws case, when using jms and using the async methods on the generated SEI, there is no reason that any thread should need to block. Once the request is sent, the original thread can go on it's merry way and when the response comes in, the workqueue would handle it and the async callback thing would get notified when done. The major problem right now is there isn't any concept of asyncronous invokes on the ClientImpl. It's all ONLY handled at the JAX-WS layer. Thus, only JAXWS can take use it, and it really isn't the right way to do it. We would need to add a bunch of API's to the ClientImpl so others that don't use JAX-WS (example: the dynamic client) can also use it. There are a couple things in the JAX-WS layer that should be pushed down a layer. The async stuff is one. The request/response contexts are another. Dan On Friday 22 August 2008 5:37:34 am 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 -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
