cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: JMS transport sync/async......
Date Mon, 27 Oct 2008 14:31:38 GMT
On Sunday 26 October 2008 9:01:44 am Christian Schneider wrote:
> Hi Dan,
>
> I have looked into ClientImpl and JMSConduit. I think the code you added
> should work.
> The JMSConduit.onMessage is called from DefaultMessageListenerContainer
> which uses a spring TaskExecutor. Additionally it can be configured
> to use several threads to listen on jms messages. So I think there is no
> need for a workqueue.

Ok.  Cool.   That's what I wanted to know.

> Additionally ClientImpl uses another executor.

Not normally, only if the user configures an executor into the client which 
isn't exactly a normal occurrance.   However, it does provide a mechanism to 
the user to workaround any issues.

> Btw. is it really necessary to do different things for sync and async?
> Of course the ClientImpl has to support a sync and async mode but I think
> the transports could be made completely async. Does the Exchange even
> has to know if it is synchronous?

It could, but HTTP and CORBA performance would certainly suffer and the number 
of threads blocked on requests in the sync cases would double.     Since part 
of what I'm trying to do is eliminate/reduce the number of blocked threads, 
that would be bad.    Basically, if a request is known to be synchronous, if 
the transports can do everything on the single thread, that's greatly 
preferred.  Otherwise, you have the ClientImpl blocking as well as a 
background thread blocking for the transport.  (along with all the context 
switches and such to flip threads through the CPU)


> About your question regarding the wait. I would like to remove the wait
> and also the config option receiveTimeout. If the Client can do this
> then that is the better solution.
> There is one thing we have to keep in mind though. The sendExchange
> method adds an entry to the correlationMap. This has to be removed after
> the timeout. Normally this is done after the wait.
> I guess there is no easy solution for this problem. 

I think the client calls into the Conduit with a "done" message or something 
at the end.   The JMS conduit should be able to do any cleanup there:
getConduitSelector().complete(exchange);

>Generally I would
> suggest doing the whole correlation already in the client. So we could
> keep this out of the transport code.

Not sure if that's completely possible.   Things like HTTP and CORBA don't 
have any correlation ID on the wire.   Thus, those transports would need to 
add stuff and record various "fake" id's and such to make that work.   
Basically, you remove it from JMS, but add it to the others.   (I think)

> Another thing are the Executors and Workqueues. The current spring
> versions already provide this functionality. Do you think it is possible
> to switch to
> the spring implementations and remove this code from cxf? 

Nope.   CXF needs to work for the "normal" usecases (JAX-WS/SOAP/HTTP) without 
spring.   That said, we could augment it to allow the spring things to be 
used instead if available/configured.

Dan


> Greetings
>
> Christian
>
> Daniel Kulp schrieb:
> > Christian,
> >
> > When you get some time, can you look at what I've done in the JMS
> > transport to make sure it's all OK and doesn't introduce some massive
> > scalability issue?
> >
> > Basically, I now call the message observer directly from the
> > onMessage(JMSMessage)  call.   This means its called on the thread that
> > the JMS queue provides instead of from the CXF calling thread.    Right
> > now, if it's a synchronous invoke, I left the "wait()" in place on the
> > main thread, but that's really not needed.    It could return immediately
> > as the ClientImpl will then wait if it's supposed to be synchronous.   I
> > mostly left it there due to the jmsTemplate.getReceiveTimeout() thing.  
> > If we return, the timeout would need to be configured on the client
> > itself,  which might not be a bad thing.   Not really sure.    Maybe the
> > default could be RECEIVE_TIMEOUT_NO_WAIT and only wait on that main
> > thread if it's set otherwise?   I don't really know, not my area of
> > expertise.
> >
> > I guess my main concern is if it's OK to process the response on the JMS
> > provided thread.   Is that part of a thread pool or similar?   If not,
> > we'll need to throw it on a workqueue.   That's easy enough to do, but I
> > wanted to hear from you first.
> >
> > Thanks!



-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message