On Fri December 18 2009 7:21:30 pm Coder One wrote: > 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.
Just to provide an extra "hint" to you to help optimize: The Exchange that is passed into the conduit (via the Message) has two methods on it that the conduit can use to optimize interactions. 1) isOneWay() - let's the conduit know this is a one-way message pattern so it can simply not setup any sort of response thing or similar. 2) isSynchronous() - this is true if the client is invoking this via a synchronous (the normal case) method. false if the async calls are being used. The second is kind of important for SOME transports. For example, with http, if it's synchronous, we just grab the response immediately and start processing. Otherwise, we need to create runnables and put it on a workqueue and context switch and all that. The runnable/workqueue thing would still work fine if syncrounous (the client impl would block waiting), but performance would be a bit lower. For JMS on trunk if asynchronous, we setup a listener and such and return immediately after sending so the thread doesn't block at all. For synchronous, we use the Spring JmsTemplate to receiveSelected to avoid having to setup the listeners and such and having background threads and all that. Dan > > --- 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
