On Fri December 18 2009 12:39:34 am Coder One wrote:
> I compared the following CXF code:
>
> LocalConduit, LocalDestination and JMSConduit, JMSDestination.
>
> Now, I am not sure whether my CustomDestination needs to derive from
> AbstractDestination or MultiplexDestination.
>
> Here is my implementation scenario:
>
> 10 threads (T1 - T10) calling "void ping()" which goes into CXF and then
> into my CustomConduit somehow.
>
> Can I set it up such that CustomConduit.prepare and CustomConduit.close be
> called by the actual threads T1 - T10? I don't want CXF to "queue" the
> SOAP representing the ping invocation anywhere.
I believe that is exactly what it DOES do. The sending is done synchronously
as the JAX-WS spec requires any IOExceptions or similar that are a result of
the transport not being able to send the message to be propagated back
immediately. Thus, the sending is done synchronously. However, if async,
once the message is sent, the thread unwinds.
One note: the Async behavior looks to be COMPLETELY broken on trunk with the
JMSConduit. I need to dig in a bit more, but it looks like the JMSConduit is
always waiting for the response directly. The 2.2.x branch looks fine.
:-(
> My CustomConduit will place the SOAP payload on the proper JMS destination.
>
> When the SOAP response comes back on some JMS destination, my
> CustomDestination extracts the SOAP payload and pushes it into "CXF".
>
> Will CXF invokes the POJO using the same thread ("my thread")that pushes
> the SOAP message?
Yes, but you COULD grab the workqueue from the bus and have your thread push
something on there that would call the CXF MessageObserver.
Dan
>
> All help greatly appreciated!
>
> --- On Thu, 12/17/09, Coder One <[email protected]> wrote:
> > From: Coder One <[email protected]>
> > Subject: Re: Async Invocation & Custom Transport
> > To: [email protected]
> > Date: Thursday, December 17, 2009, 10:30 AM
> > 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
