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