Hi Ron,
Yes, servicemix-cxf-bc provider almost do same thing as cxf ClientImpl
do (like create interceptor chain, invoke interceptor and register
incoming message observer).
We can add some code for servicemix-cxf-bc provider like create another
thread to invoke interceptor to send request so that the main thread
will not get blocked when waiting response, but I believe it's not what
you really want like your described in another mail
"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..."
servicemix-cxf-bc provider will reuse jms transport of cxf, so the
synchronized way how JMSConduit send out message and handleResponse
(block for response message until client timeout) currently may need
change. I will post thread on cxf-dev list to discuss this issue.
Regards
Freeman
rgavlin wrote:
Greetings,
I have an asynchronous pipeline using either an smx-cxf-bc provider or
camel-cxf as its transformer. Assume the pipeline is sending a large number
of async, in-out meps to the cxf-based transformer concurrently in order to
invoke an external, request-response cxf-hosted service using the jms
transport.
In order for this solution to scale, the cxf-based transformer cannot send
the request to the external service and then wait for the response on the
same thread. Based on Dan's post
"http://www.nabble.com/Does-SMX-CXF-BC-provider-w-JMS-transport-block-thread-waiting-for-a-reply--tp19102173p19105489.html";,
it appears this is how the cxf "ClientImpl" works currently regardless of
the transport. Therefore, I suspect that the smx-cxf-bc provider and
camel-cxf behave similarly since they likely inherit this functionality from
the cxf "ClientImpl".
Is this true for the smx-cxf-bc provider?
Is it true for camel-cxf?
In order for the smx-cxf-bc provider and camel-cxf to scale, the thread
sending the request should complete after the request is successfully sent.
Then a thread or thread pool should be listening on the reply-to queue. When
the reply is received, it should be correlated to the original message
exchange and returned to the pipeline.
Must the cxf "ClientImpl" be upgraded to deliver this functionality or could
the smx-cxf-bc provider and camel-cxf be enhanced independently to provide
this functionality? It sounds like enhancing the cxf "ClientImpl" will
likely require API changes that would not be doable in a CXF 2.0.x or even
2.1.x branch. Of course, I would like to see this scalability issue
addressed sooner than later.
Let me know your thoughts.
- Ron
