Hi Dan, Thanks for the update.
This seems like a major impediment to using CXF as the engine underneath a JBI BC Provider. The value proposition of the ESB is scalable, async messaging. When one component in the ESB integration process introduces a choke-point, the entire process becomes unscalable. - Ron dkulp wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Does-SMX-CXF-BC-provider-w-JMS-transport-block-thread-waiting-for-a-reply--tp19102173p19107458.html Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
