cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: JMS transport sync/async......
Date Mon, 27 Oct 2008 18:02:14 GMT
Daniel Kulp schrieb:
>> 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)
I don´t think that this has to be the case. An async http request could 
send the request and store the http session in the message.
Then it could return. The client would then call another function to 
wait for the response. I am not yet sure how this could work but I will
try to work out something that works equally well with http and jms.
> 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);
If I understand this right then this method calls the close(Message) 
method on the conduit. So this is where I should remove the correlation?
For this to work I have to encode the correlationId in the Message or 
the Exchange. Any idea where I should put it? Should I create a new map 
key for this or is there a default place for correlationIds?
>> 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)
HTTP may not need a correlationId in its normal snychronous way. But 
there are use cases where two separate http connections are used for 
request and reply.
I think microsoft calls this duplex mode in wcf. In this case HTTP would 
work like JMS. I am not sure if this modeis relevant in java but it 
could be used in one of the ws* specs.
>> 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.
Hmm I understand that it is not always necessary to use a spring 
context. But wouldn´t it be better to let a more generic framework like 
spring solve things like Executors and Workqueues?




Christian Schneider

View raw message