You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Freeman Fang <fr...@gmail.com> on 2008/08/25 09:28:21 UTC
can we use asyn way for jms transport
Hi,
Currently we are using sync way for jms transport which means the thread
get blocked until response messsage is coming or the client side
timeout, see the handleResponse() method of JMSConduit? Is it possible
that we use non-block way for JMSConduit, something like implement JMS
MessageListener API? Or any special reason we need this sync invocation
for JMS conduit?
Thanks
Freeman
Re: can we use asyn way for jms transport
Posted by Daniel Kulp <dk...@apache.org>.
As I mentioned on the ServiceMix dev list, there is a "deficiency" in
the "Client" API that would make this change relatively moot unless the
client API is completely updated. Right now, async invokations are only
available to the jax-ws frontend, and that's really just "faked" via doing a
sync invokation on a background thread (which then blocks). We would
definitely need to get the Client API's updated to support async concepts a
bit better before the transports can really be updated to take advantage of
it.
Dan
On Monday 25 August 2008 3:28:21 am Freeman Fang wrote:
> Hi,
>
> Currently we are using sync way for jms transport which means the thread
> get blocked until response messsage is coming or the client side
> timeout, see the handleResponse() method of JMSConduit? Is it possible
> that we use non-block way for JMSConduit, something like implement JMS
> MessageListener API? Or any special reason we need this sync invocation
> for JMS conduit?
>
> Thanks
> Freeman
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: can we use asyn way for jms transport
Posted by rgavlin <rg...@yahoo.com>.
Hi Freeman,
FYI, you might take a look at
http://svn.apache.org/viewvc/servicemix/components/bindings/servicemix-jms/trunk/src/main/java/org/apache/servicemix/jms/endpoints/JmsConsumerEndpoint.java?view=markup
and AbstractConsumerEndpoint.java for a sample usage of the Spring JMS
MessageListenerContainer. I suspect it will be applicable for handling both
the request queue and the response queue.
- Ron
Freeman Fang wrote:
>
> Hi Ulhas,
>
> Thanks.
>
> How about we introduce Spring JmsTemplate to cxf jms transport, is it
> helpful? I'm not familar with spring JmsTemplate but I wanna get more
> ideas about it .
>
> Thanks again
>
> Freeman
>
> Ulhas Bhole wrote:
>> Hi Freeman,
>>
>> I was looking at code and here are two main problems that we will need
>> to tackle.
>>
>> 1. By default, we create separate TemporaryQueue for repsonse so we
>> will need receiver per tempqueue waiting on reply. (so that many threds.)
>> 2. to propogate the JMS response headers back we use JAXWS
>> responseContext which I assume is threadlocal so we need to find out
>> how it will react when the response goes on different thread.
>>
>> If we ignore for moment point 2 we will either need to use one
>> TemporaryQueue for all responses if no replyDestination is defined.
>> Also will neeed to have separate pool of listeners for scalability.(I
>> don't know how the JMS callback works so will need to look into it
>> more)
>>
>> Regards,
>>
>> Ulhas Bhole
>> Freeman Fang wrote:
>>> Any thoughts?
>>>
>>> Cheers
>>> Freeman
>>>
>>>
>>> Freeman Fang wrote:
>>>> Hi,
>>>>
>>>> Currently we are using sync way for jms transport which means the
>>>> thread get blocked until response messsage is coming or the client
>>>> side timeout, see the handleResponse() method of JMSConduit? Is it
>>>> possible that we use non-block way for JMSConduit, something like
>>>> implement JMS MessageListener API? Or any special reason we need
>>>> this sync invocation for JMS conduit?
>>>>
>>>> Thanks
>>>> Freeman
>>>>
>>>>
>>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>>
>
>
>
--
View this message in context: http://www.nabble.com/can-we-use-asyn-way-for-jms-transport-tp19139208p19158981.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: can we use asyn way for jms transport
Posted by Ulhas Bhole <ul...@iona.com>.
Hi Freeman,
As per 2.2 roadmap ideas we want to change/rewrite CXF JMS transport to
support SPEC/JMS and use spring JMSTemplates but I guess we need to do
it in such a way that we can keep the current one if someone already
using it atleast for some time.
I didn't got a chance to look at how we can integrate both (SPEC/JMS and
spring jmsTemplate together) in CXF JMS transport. I would surely be in
favor of the new transport which would be more flexible than the current
one.
Regards,
Ulhas Bhole
Freeman Fang wrote:
> Hi Ulhas,
>
> Thanks.
>
> How about we introduce Spring JmsTemplate to cxf jms transport, is it
> helpful? I'm not familar with spring JmsTemplate but I wanna get more
> ideas about it .
>
> Thanks again
>
> Freeman
>
> Ulhas Bhole wrote:
>> Hi Freeman,
>>
>> I was looking at code and here are two main problems that we will
>> need to tackle.
>>
>> 1. By default, we create separate TemporaryQueue for repsonse so we
>> will need receiver per tempqueue waiting on reply. (so that many
>> threds.)
>> 2. to propogate the JMS response headers back we use JAXWS
>> responseContext which I assume is threadlocal so we need to find out
>> how it will react when the response goes on different thread.
>>
>> If we ignore for moment point 2 we will either need to use one
>> TemporaryQueue for all responses if no replyDestination is defined.
>> Also will neeed to have separate pool of listeners for scalability.(I
>> don't know how the JMS callback works so will need to look into it
>> more)
>>
>> Regards,
>>
>> Ulhas Bhole
>> Freeman Fang wrote:
>>> Any thoughts?
>>>
>>> Cheers
>>> Freeman
>>>
>>>
>>> Freeman Fang wrote:
>>>> Hi,
>>>>
>>>> Currently we are using sync way for jms transport which means the
>>>> thread get blocked until response messsage is coming or the client
>>>> side timeout, see the handleResponse() method of JMSConduit? Is it
>>>> possible that we use non-block way for JMSConduit, something like
>>>> implement JMS MessageListener API? Or any special reason we need
>>>> this sync invocation for JMS conduit?
>>>>
>>>> Thanks
>>>> Freeman
>>>>
>>>>
>>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: can we use asyn way for jms transport
Posted by Willem Jiang <wi...@gmail.com>.
Just FYI, it is very easy to use camel-jms component (which uses the
Spring JMS template) as a new JMS transport in CXF.
Also here a blog[1] which discusses about it.
[1]
http://www.liquid-reality.de:8080/display/liquid/2008/08/25/Better+JMS+Transport+for+CXF+Webservice+using+Apache+Camel
Willem
Freeman Fang wrote:
> Hi Ulhas,
>
> Thanks.
>
> How about we introduce Spring JmsTemplate to cxf jms transport, is it
> helpful? I'm not familar with spring JmsTemplate but I wanna get more
> ideas about it .
>
> Thanks again
>
> Freeman
>
> Ulhas Bhole wrote:
>> Hi Freeman,
>>
>> I was looking at code and here are two main problems that we will
>> need to tackle.
>>
>> 1. By default, we create separate TemporaryQueue for repsonse so we
>> will need receiver per tempqueue waiting on reply. (so that many
>> threds.)
>> 2. to propogate the JMS response headers back we use JAXWS
>> responseContext which I assume is threadlocal so we need to find out
>> how it will react when the response goes on different thread.
>>
>> If we ignore for moment point 2 we will either need to use one
>> TemporaryQueue for all responses if no replyDestination is defined.
>> Also will neeed to have separate pool of listeners for scalability.(I
>> don't know how the JMS callback works so will need to look into it
>> more)
>>
>> Regards,
>>
>> Ulhas Bhole
>> Freeman Fang wrote:
>>> Any thoughts?
>>>
>>> Cheers
>>> Freeman
>>>
>>>
>>> Freeman Fang wrote:
>>>> Hi,
>>>>
>>>> Currently we are using sync way for jms transport which means the
>>>> thread get blocked until response messsage is coming or the client
>>>> side timeout, see the handleResponse() method of JMSConduit? Is it
>>>> possible that we use non-block way for JMSConduit, something like
>>>> implement JMS MessageListener API? Or any special reason we need
>>>> this sync invocation for JMS conduit?
>>>>
>>>> Thanks
>>>> Freeman
>>>>
>>>>
>>>>
>>
>> ----------------------------
>> IONA Technologies PLC (registered in Ireland)
>> Registered Number: 171387
>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>> Ireland
>>
>
>
Re: can we use asyn way for jms transport
Posted by Freeman Fang <fr...@gmail.com>.
Hi Ulhas,
Thanks.
How about we introduce Spring JmsTemplate to cxf jms transport, is it
helpful? I'm not familar with spring JmsTemplate but I wanna get more
ideas about it .
Thanks again
Freeman
Ulhas Bhole wrote:
> Hi Freeman,
>
> I was looking at code and here are two main problems that we will need
> to tackle.
>
> 1. By default, we create separate TemporaryQueue for repsonse so we
> will need receiver per tempqueue waiting on reply. (so that many threds.)
> 2. to propogate the JMS response headers back we use JAXWS
> responseContext which I assume is threadlocal so we need to find out
> how it will react when the response goes on different thread.
>
> If we ignore for moment point 2 we will either need to use one
> TemporaryQueue for all responses if no replyDestination is defined.
> Also will neeed to have separate pool of listeners for scalability.(I
> don't know how the JMS callback works so will need to look into it
> more)
>
> Regards,
>
> Ulhas Bhole
> Freeman Fang wrote:
>> Any thoughts?
>>
>> Cheers
>> Freeman
>>
>>
>> Freeman Fang wrote:
>>> Hi,
>>>
>>> Currently we are using sync way for jms transport which means the
>>> thread get blocked until response messsage is coming or the client
>>> side timeout, see the handleResponse() method of JMSConduit? Is it
>>> possible that we use non-block way for JMSConduit, something like
>>> implement JMS MessageListener API? Or any special reason we need
>>> this sync invocation for JMS conduit?
>>>
>>> Thanks
>>> Freeman
>>>
>>>
>>>
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
Re: can we use asyn way for jms transport
Posted by Ulhas Bhole <ul...@iona.com>.
Hi Freeman,
I was looking at code and here are two main problems that we will need
to tackle.
1. By default, we create separate TemporaryQueue for repsonse so we will
need receiver per tempqueue waiting on reply. (so that many threds.)
2. to propogate the JMS response headers back we use JAXWS
responseContext which I assume is threadlocal so we need to find out how
it will react when the response goes on different thread.
If we ignore for moment point 2 we will either need to use one
TemporaryQueue for all responses if no replyDestination is defined. Also
will neeed to have separate pool of listeners for scalability.(I don't
know how the JMS callback works so will need to look into it more)
Regards,
Ulhas Bhole
Freeman Fang wrote:
> Any thoughts?
>
> Cheers
> Freeman
>
>
> Freeman Fang wrote:
>> Hi,
>>
>> Currently we are using sync way for jms transport which means the
>> thread get blocked until response messsage is coming or the client
>> side timeout, see the handleResponse() method of JMSConduit? Is it
>> possible that we use non-block way for JMSConduit, something like
>> implement JMS MessageListener API? Or any special reason we need this
>> sync invocation for JMS conduit?
>>
>> Thanks
>> Freeman
>>
>>
>>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: can we use asyn way for jms transport
Posted by Freeman Fang <fr...@gmail.com>.
Any thoughts?
Cheers
Freeman
Freeman Fang wrote:
> Hi,
>
> Currently we are using sync way for jms transport which means the
> thread get blocked until response messsage is coming or the client
> side timeout, see the handleResponse() method of JMSConduit? Is it
> possible that we use non-block way for JMSConduit, something like
> implement JMS MessageListener API? Or any special reason we need this
> sync invocation for JMS conduit?
>
> Thanks
> Freeman
>
>
>