On Monday 27 October 2008 2:02:14 pm Christian Schneider wrote: > Daniel Kulp schrieb: > > 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'm not sure this is possible without changing the API of the conduit which isn't something we can due to compatibility with out of tree transports. (mule, smx, etc...) If you can do it, great. :-) > > 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? There isn't a place for it. If this is JMS only, you can just use any key you want. Define a string in JMSConduit like: JMSConduit.class.getName() + ".correlationId" or similar and set that on the message/exchange and retrieve it later. > > 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. This is done via ws-addressing which puts the correlation information into the ws-addressing headers and such and the ws-addressing interceptors handle those correlation things. > >> 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? Sure, as long as it doesn't HAVE to always use those things. :-) -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
