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
