You are fantastically helpful! We are just about to seriously hit the custom transport, so this will help!
Thanks! --- On Mon, 12/21/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: Monday, December 21, 2009, 9:16 AM > 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 >
