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? 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 >
