About not using CXF JMS, we need to support multiple non-java platform with perhaps a somewhat specialized JMS semantics, so we thought it would be best for us to be in full control of the transport, just in case.
Thanks for all your help! Really appreciate it. --- On Fri, 12/18/09, Daniel Kulp <[email protected]> wrote: > From: Daniel Kulp <[email protected]> > Subject: Re: Async Invocation & Custom Transport > To: [email protected] > Cc: "Coder One" <[email protected]> > Date: Friday, December 18, 2009, 12:32 PM > On Thu December 17 2009 1:30:31 pm > Coder One wrote: > > Hi, > > > > I had a typo. I mean CXF (not sure how Camel > snuck in there :)) > > > > I don't plan to use CXF JMS transport, but rather add > our own transport > > which uses JMS. So, somethign like > > > > CXF <-interface1-> CxfTransportJms > <-> JMS > > CXF <-interface2-> CustomTransportJms > <-> JMS > > > > What does interface2 looks like from a thread > perspective? > > Out of curiosity, any reason why the CXF JMS transport > cannot be used? > > It MAY be easier to just wrapper your stuff in a Spring > AbstractMessageListenerContainer and configure that into > CXF's JMS transport. > > Dan > > > > > > Thanks... > > > > --- On Thu, 12/17/09, Daniel Kulp <[email protected]> > wrote: > > > From: Daniel Kulp <[email protected]> > > > Subject: Re: Async Invocation & Custom > Transport > > > To: [email protected] > > > Cc: "Coder One" <[email protected]> > > > Date: Thursday, December 17, 2009, 9:39 AM > > > On Thu December 17 2009 11:49:02 am > > > > > > Coder One wrote: > > > > Hi, > > > > > > > > Internally, how does Camel handle Async > > > > > > invocation? If "a million" threads > > > > > > > invokes "public Future<?> > > > > > > greetMeSometimeAsync", how does CXF track the > > > > > > > SOAP messages? > > > > > > Not sure on Camel, but for CXF, it really kind of > depends > > > on the transport. > > > For HTTP, right now, we don't have much choice > except to > > > use a thread as we > > > aren't using a non-blocking http > > > client. If someone ever tackles > the task of > > > > > > creating an http-client based conduit or a > jetty-client > > > based conduit, we > > > could possibly revisit that. > > > > > > For JMS, we now just register a listener and > > > return. The listener will fire > > > off when the queue gets the message. > > > Thus, with JMS, we don't tie up any > > > threads on the client for the async calls. > > > > > > Dan > > > > > > > We plan to use our own custom (not based on > CXF JMS, > > > > > > not Camel) JMS > > > > > > > transport, so we would like to ensure > that: > > > > > > > > 1. CXF delegates the queuing of SOAP > messages to our > > > > > > transport, which in > > > > > > > turn will rely on JMS. 2. CXF > interfaces with > > > > > > our custom transport in a > > > > > > > non-blocking mode. 2a. This is to > avoid CXF > > > > > > internally creates a "million" > > > > > > > threads blocking on a response. > > > > > > > > Thanks for all your help! > > > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog >
