You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Coder One <co...@yahoo.com> on 2009/12/17 17:49:02 UTC
Async Invocation & Custom Transport
Hi,
Internally, how does Camel handle Async invocation? If "a million" threads invokes "public Future<?> greetMeSometimeAsync", how does CXF track the SOAP messages?
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!
Re: Async Invocation & Custom Transport
Posted by Coder One <co...@yahoo.com>.
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 <dk...@apache.org> wrote:
> From: Daniel Kulp <dk...@apache.org>
> Subject: Re: Async Invocation & Custom Transport
> To: users@cxf.apache.org
> Cc: "Coder One" <co...@yahoo.com>
> 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 <dk...@apache.org>
> wrote:
> > > From: Daniel Kulp <dk...@apache.org>
> > > Subject: Re: Async Invocation & Custom
> Transport
> > > To: users@cxf.apache.org
> > > Cc: "Coder One" <co...@yahoo.com>
> > > 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 <dk...@apache.org>
> > >
> > > wrote:
> > > > > From: Daniel Kulp <dk...@apache.org>
> > > > > Subject: Re: Async Invocation &
> Custom
> > >
> > > Transport
> > >
> > > > > To: users@cxf.apache.org
> > > > > Cc: "Coder One" <co...@yahoo.com>
> > > > > 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Async Invocation & Custom Transport
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@apache.org> wrote:
> > From: Daniel Kulp <dk...@apache.org>
> > Subject: Re: Async Invocation & Custom Transport
> > To: users@cxf.apache.org
> > Cc: "Coder One" <co...@yahoo.com>
> > 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 <dk...@apache.org>
> >
> > wrote:
> > > > From: Daniel Kulp <dk...@apache.org>
> > > > Subject: Re: Async Invocation & Custom
> >
> > Transport
> >
> > > > To: users@cxf.apache.org
> > > > Cc: "Coder One" <co...@yahoo.com>
> > > > 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Async Invocation & Custom Transport
Posted by Coder One <co...@yahoo.com>.
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.
--- On Fri, 12/18/09, Daniel Kulp <dk...@apache.org> wrote:
> From: Daniel Kulp <dk...@apache.org>
> Subject: Re: Async Invocation & Custom Transport
> To: users@cxf.apache.org
> Cc: "Coder One" <co...@yahoo.com>
> 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 <dk...@apache.org>
> wrote:
> > > From: Daniel Kulp <dk...@apache.org>
> > > Subject: Re: Async Invocation & Custom
> Transport
> > > To: users@cxf.apache.org
> > > Cc: "Coder One" <co...@yahoo.com>
> > > 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Async Invocation & Custom Transport
Posted by Daniel Kulp <dk...@apache.org>.
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 <dk...@apache.org> wrote:
> > From: Daniel Kulp <dk...@apache.org>
> > Subject: Re: Async Invocation & Custom Transport
> > To: users@cxf.apache.org
> > Cc: "Coder One" <co...@yahoo.com>
> > 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Posted by Coder One <co...@yahoo.com>.
Hi,
I was thinking about the problem of running Spring 2.5.6 out of the box with 5.1.0. I saw some reports on issue with Spring 3.0.0 M
"xyz" releases but have not checked the 3.0.0 release yet.
It has to do with the loading of Spring context file. It seems like that there is a workaround / fix already, so I was fishing to see if there were other issues beneath...
Thanks...
----- Original Message ----
From: Alessio Soldano <as...@redhat.com>
To: users@cxf.apache.org
Sent: Fri, December 18, 2009 12:34:56 AM
Subject: Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Coder One wrote:
> JBOSS 5.1.0 has that screwy vfszip problem...
>
perhaps I can give a suggestion here... what exact problem are you referring to?
Cheers
Alessio
-- Alessio Soldano
Web Service Lead, JBoss
Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Posted by Alessio Soldano <as...@redhat.com>.
Coder One wrote:
> JBOSS 5.1.0 has that screwy vfszip problem...
>
perhaps I can give a suggestion here... what exact problem are you
referring to?
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: Conduit versus Destination
Posted by Eoghan Glynn <eo...@gmail.com>.
Almost right.
Strictly speaking, its not necessarily SOAP that's being sent in the payload
(could for example be plain ol' XML or JSON instead).
Also, for sending responses back from the server side, a back-channel
Conduit[1] is used.
Cheers,
Eoghan
[1]
http://cxf.apache.org/javadoc/latest/org/apache/cxf/transport/Destination.html#getBackChannel(org.apache.cxf.message.Message,%20org.apache.cxf.message.Message,%20org.apache.cxf.ws.addressing.EndpointReferenceType)
2009/12/18 Coder One <co...@yahoo.com>
> Conduit sending and receiving SOAP on the client side?
> Destination receiving and sending SOAP on the server side?
>
> Thanks...
>
>
>
>
Conduit versus Destination
Posted by Coder One <co...@yahoo.com>.
Conduit sending and receiving SOAP on the client side?
Destination receiving and sending SOAP on the server side?
Thanks...
Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Posted by Coder One <co...@yahoo.com>.
Excellent news. Thanks!
--- On Thu, 12/17/09, Daniel Kulp <dk...@apache.org> wrote:
> From: Daniel Kulp <dk...@apache.org>
> Subject: Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
> To: users@cxf.apache.org
> Cc: "Coder One" <co...@yahoo.com>
> Date: Thursday, December 17, 2009, 6:02 PM
>
> Funny you should bring this up. I just
> started running tests with Spring3
> today. The only major issue I found is the
> JMS transport seems to have some
> problems with Spring3. I fixed that today so
> 2.2.6 should definitely be OK
> with Spring 3. Other than that, everything
> else seems to be OK. We have
> two test failures related to Spring Security integration
> that I haven't looked
> into yet, but all the other tests now pass.
>
> There WAS a problem with one of the Spring3 RC's, but they
> reverted the change
> for the release.
>
> Dan
>
> On Thu December 17 2009 6:46:48 pm Coder One wrote:
> > Is the following combination supported? I saw
> some messages flying around
> > about Spring 3.0.x and CXF incompatibility, so
> just want to be sure.
> >
> > JBOSS 5.1.0 has that screwy vfszip problem...
> >
> > CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
> >
> > Thanks,
> >
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Posted by Daniel Kulp <dk...@apache.org>.
Funny you should bring this up. I just started running tests with Spring3
today. The only major issue I found is the JMS transport seems to have some
problems with Spring3. I fixed that today so 2.2.6 should definitely be OK
with Spring 3. Other than that, everything else seems to be OK. We have
two test failures related to Spring Security integration that I haven't looked
into yet, but all the other tests now pass.
There WAS a problem with one of the Spring3 RC's, but they reverted the change
for the release.
Dan
On Thu December 17 2009 6:46:48 pm Coder One wrote:
> Is the following combination supported? I saw some messages flying around
> about Spring 3.0.x and CXF incompatibility, so just want to be sure.
>
> JBOSS 5.1.0 has that screwy vfszip problem...
>
> CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
>
> Thanks,
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Posted by Coder One <co...@yahoo.com>.
Is the following combination supported? I saw some messages flying around about Spring 3.0.x and CXF incompatibility, so just want to be sure.
JBOSS 5.1.0 has that screwy vfszip problem...
CXF 2.2.5 JBOSS 5.1.0.GA Spring 3.0.0
Thanks,
Re: Async Invocation & Custom Transport
Posted by Daniel Kulp <dk...@apache.org>.
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 <co...@yahoo.com> wrote:
> > From: Coder One <co...@yahoo.com>
> > Subject: Re: Async Invocation & Custom Transport
> > To: users@cxf.apache.org
> > 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 <dk...@apache.org>
> >
> > wrote:
> > > From: Daniel Kulp <dk...@apache.org>
> > > Subject: Re: Async Invocation & Custom Transport
> > > To: users@cxf.apache.org
> > > Cc: "Coder One" <co...@yahoo.com>
> > > 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: Async Invocation & Custom Transport
Posted by Coder One <co...@yahoo.com>.
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 <co...@yahoo.com> wrote:
> From: Coder One <co...@yahoo.com>
> Subject: Re: Async Invocation & Custom Transport
> To: users@cxf.apache.org
> 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 <dk...@apache.org>
> wrote:
>
> > From: Daniel Kulp <dk...@apache.org>
> > Subject: Re: Async Invocation & Custom Transport
> > To: users@cxf.apache.org
> > Cc: "Coder One" <co...@yahoo.com>
> > 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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
>
>
>
>
Re: Async Invocation & Custom Transport
Posted by Coder One <co...@yahoo.com>.
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 <dk...@apache.org> wrote:
> From: Daniel Kulp <dk...@apache.org>
> Subject: Re: Async Invocation & Custom Transport
> To: users@cxf.apache.org
> Cc: "Coder One" <co...@yahoo.com>
> 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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Async Invocation & Custom Transport
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://www.dankulp.com/blog