You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Florent BENOIT <Fl...@ow2.org> on 2011/07/08 14:23:07 UTC
[DISCUSSION] Introducing a new Reliable JMS CXF Transport
Hi CXF guys,
I would like to introduce a new CXF transport that we've developed and
that could be contributed back to the CXF community. It is called
"Reliable JMS transport"
When this transport has been designed, the goal was to have a reliable
transport that we could called "Enterprise Transport" as we wanted to
use transactions and JMS by using containers like Java EE EJB or Spring
MDP (we support both). We don't want to loose any requests or answers
and we want to avoid waiting threads. This transport has not been
designed from scratch as it is using the JMS layer and share some
classes with the current CXF JMS transport but there are some
differences between them. But we couldn't change the current transport
as the design is not the same.
First, let me give you details about this transport and why it's
different from the current JMS CXF transport.
The current CXF JMS transport is not reliable. For example, if you
restart a client or a server you may loose some requests/answers. This
is because the mechanism that is used is keeping data in memory. So
after a JVM crash, all the data are lost.
Also, for this new transport, we wanted to guarantee the delivery so it
is using transactions. (A transaction manager is then required).
As said before, we wanted to avoid the use of threads waiting for an
answer. If there are 100 requests, we don't want 100 threads waiting
their answer. This is because we can use either EJB MDB or Spring MDP to
handle the answer. In this way, resources are allocated only if an
answer is handled and not during all the waiting time. So the number of
threads is dramatically reduced. Also by relying on EJB MDB or Spring
MDP we're based on existing patterns.
Here is a link to the documentation of this transport and pictures that
are illustrating this solution :
http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
This illustrates how the
And the errors handling that is working with all kind of JVM crash :
http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png
There are integration tests included in this transport that are launched
through our continous integration tool on http://bamboo.ow2.org
For now, they're using JOnAS as Java EE server as we need a JTA manager
and we test both EJB MDB and Spring MDP providers.
To sum up, is there an interest in CXF to integrate this transport ?
What kind of changes need to be done, etc.
Also I hope to get some feedback about this protocol.
Regards,
Florent
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by Daniel Kulp <dk...@apache.org>.
I haven't really had time to look at this at all, but a couple comments.....
On Friday, July 08, 2011 9:23:05 PM Guillaume Sauthier wrote:
> If you look at the global picture:
> http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/
> cxf-reliablejms-execution-flow-simple-english.png
>
> you'll notice that the client is split in 2 parts: the initiator (initiates
> the call) and the handler (process the result).
>
> We don't use the JAXWS AsyncHandler API because it is tightly coupled to the
> execution context of the client initiator: maybe the handler has some ref
> to live objects that we cannot persist and/or recreate if the initiator JVM
> crashes.
> In order to bypass this issue, we had to tweak the jaxws development model a
> little bit:
> * on initiator side, we use the normal (synchronous) generated API, but the
> stub always returns null (as the call was synchronous, the answer is not
> there yet)
This is what concerns me the most and would be my #1 complaint. This really
kind of abuses the JAX-WS API's quite a bit which makes me a bit
uncomfortable. I think I'd really prefer something that doesn't really
abuse the JAX-WS API's like that. For the most part, I'd want to keep the
API's working as advertised, but possibly with extended behavior.
I'd also DEFINITELY prefer a solution that doesn't require spring or is very
easily to decouple from Spring. A lot of work was put into 2.4 to minimize
the Spring requirements.
There are three types of JAX-WS methods we need to consider.
For the Async methods that return a Response<Foo> type thing, we're completely
in control of that return object. Thus, that object can be restoreable
(serializable or similar) and passed back. The client can use it to poll when
the response is there, etc...
The non-async method should, IMO, just work as designed. It should block
until the return is avail. It COULD be implemented in terms of the
Response<Foo> thing above.
For the Async method that takes the AsyncHandler, we should use it. It COULD
also optionally implement additional CXF specific interfaces to help handle
saving/restoring it.
Anyway, those are my initial thoughts. I also agree with Christian that
having a single JMS transport is also preferred, but not a "huge" requirement.
Dan
> * the initiator provides an AsynchHandler through the Spring application
> context, this handler will be notified when a response will be posted on the
> response queue. As this object is created from Spring beans, it is
> decoupled from the initiator execution context and can be safely used.
> * The request flow is quite normal: we define a <jaxws:client> on the client
> side, a <jaxws:endpoint> on the server side
> * But the response flow is different than what we could expect: the client
> also defines a <jaxws:endpoint> that will be invoked when JMS messages will
> be posted on the response queue.
>
> As everything is transactional, we have dead message queues, so that we
> never lost any messages.
>
> Hope that helps to understand this potential contribution.
>
> Thanks
> --Guillaume
>
>
> 2011/7/8 Christian Schneider <ch...@die-schneider.net>
>
> > Yes request / response correlation is definately a place where we
> > currently loose message when the client goes down.
> >
> > I think this is o big issue though as you typically only use request
> > response when you wait for the response. So normally you will even want
> > the responses to be lost when the client goes down. In the one way case
> > we should not loose messages as we can also use transactions.
> >
> > Still your JMS transport my be interesting. When doing the refactoring
> > to
> > spring jms templates and message listener I also thought about making
> > the
> > transport more asynchronous but never really did it.
> > So I would like to compare your implementation with the current one in
> > cxf.
> >
> > I would not like to have both though. If your transport is more suitable
> > we should throw the other away. In any case we should only have one JMS
> > transport.
> >
> > Christian
> >
> > Am 08.07.2011 14:39, schrieb Florent BENOIT:
> > Hi,
> >>
> >> One example about the "reliable" stuff is that we should include
> >> "recovery".
> >> For example the correlation map used to match JMS replies is stored in
> >> memory [1]
> >> 341 Exchange exchange = correlationMap.remove(**correlationId);
> >> 342 if (exchange == null) {
> >> 343 LOG.log(Level.WARNING, "Could not correlate message with
> >> correlationId " + correlationId);
> >> 344 return;
> >> 345 }
> >>
> >>
> >> So, if the JVM of the client is restarted, we will loose any replies
> >> as we won't know how to match the reply.
> >> Also, there is no JTA used with the current JMS transport. It means
> >> that
> >> we can loose data or to get some messages twice or so one.
> >>
> >> So even by using ActiveMQ with the messages being stored on the disk,
> >> this won't work after a restart.
> >>
> >> [1] :
> >> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
> >> src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
> >> view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/s
> >> rc/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup>
> >>
> >> Regards,
> >>
> >> Florent
> >>
> >> On 07/08/2011 02:25 PM, Benson Margulies wrote:
> >>> I'm confused. If you use AMQ configured for reliable storage on
> >>> disk,
> >>> how do you lose things with the existing CXF transport?
> >>>
> >>> On Fri, Jul 8, 2011 at 8:23 AM, Florent
> >>> BENOIT<Fl...@ow2.org>
> >>>
> >>> wrote:
> >>>> Hi CXF guys,
> >>>>
> >>>> I would like to introduce a new CXF transport that we've developed
> >>>> and
> >>>> that
> >>>> could be contributed back to the CXF community. It is called
> >>>> "Reliable
> >>>> JMS
> >>>> transport"
> >>>>
> >>>> When this transport has been designed, the goal was to have a
> >>>> reliable
> >>>> transport that we could called "Enterprise Transport" as we wanted
> >>>> to
> >>>> use
> >>>> transactions and JMS by using containers like Java EE EJB or
> >>>> Spring MDP (we
> >>>> support both). We don't want to loose any requests or answers and
> >>>> we
> >>>> want to
> >>>> avoid waiting threads. This transport has not been designed from
> >>>> scratch as
> >>>> it is using the JMS layer and share some classes with the current
> >>>> CXF
> >>>> JMS
> >>>> transport but there are some differences between them. But we
> >>>> couldn't
> >>>> change the current transport as the design is not the same.
> >>>>
> >>>> First, let me give you details about this transport and why it's
> >>>> different
> >>>> from the current JMS CXF transport.
> >>>>
> >>>> The current CXF JMS transport is not reliable. For example, if you
> >>>> restart a
> >>>> client or a server you may loose some requests/answers. This is
> >>>> because the
> >>>> mechanism that is used is keeping data in memory. So after a JVM
> >>>> crash, all
> >>>> the data are lost.
> >>>> Also, for this new transport, we wanted to guarantee the delivery
> >>>> so it is
> >>>> using transactions. (A transaction manager is then required).
> >>>> As said before, we wanted to avoid the use of threads waiting for
> >>>> an
> >>>> answer.
> >>>> If there are 100 requests, we don't want 100 threads waiting their
> >>>> answer.
> >>>> This is because we can use either EJB MDB or Spring MDP to handle
> >>>> the
> >>>> answer. In this way, resources are allocated only if an answer is
> >>>> handled
> >>>> and not during all the waiting time. So the number of threads is
> >>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP
> >>>> we're
> >>>> based
> >>>> on existing patterns.
> >>>>
> >>>> Here is a link to the documentation of this transport and pictures
> >>>> that are
> >>>> illustrating this solution :
> >>>> http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/**
> >>>> ReliableJMS_Transport_CXF<http://wiki.jonas.ow2.org/xwiki/bin/view
> >>>> /Main/ReliableJMS_Transport_CXF> This illustrates how the
> >>>>
> >>>> And the errors handling that is working with all kind of JVM crash
> >>>> :
> >>>> http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/**
> >>>> ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-**
> >>>> simple-failure-english.png<http://wiki.jonas.ow2.org/xwiki/bin/dow
> >>>> nload/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flo
> >>>> w-simple-failure-english.png>
> >>>>
> >>>> There are integration tests included in this transport that are
> >>>> launched through our continous integration tool on
> >>>> http://bamboo.ow2.org For now, they're using JOnAS as Java EE
> >>>> server as we need a JTA manager and
> >>>> we test both EJB MDB and Spring MDP providers.
> >>>>
> >>>> To sum up, is there an interest in CXF to integrate this transport
> >>>> ?
> >>>> What
> >>>> kind of changes need to be done, etc.
> >>>> Also I hope to get some feedback about this protocol.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Florent
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by "Guillaume Sauthier (Objectweb)" <gu...@objectweb.org>.
Hi Christian
I'm happy to see that you're interested to discuss this contribution.
I don't know if/when you may take some time to compare the 2
implementations, but if we can help in any way, let us know.
For example, we could, from our POV, list the differences between the 2
transports, at least a first draft that you could review/enhance in order to
make up your mind.
Regards
--Guillaume
2011/7/8 Christian Schneider <ch...@die-schneider.net>
> Yes request / response correlation is definately a place where we currently
> loose message when the client goes down.
>
> I think this is o big issue though as you typically only use request
> response when you wait for the response. So normally you will even want the
> responses to be lost when the client goes down. In the one way case we
> should not loose messages as we can also use transactions.
>
> Still your JMS transport my be interesting. When doing the refactoring to
> spring jms templates and message listener I also thought about making the
> transport more asynchronous but never really did it.
> So I would like to compare your implementation with the current one in cxf.
>
> I would not like to have both though. If your transport is more suitable we
> should throw the other away. In any case we should only have one JMS
> transport.
>
> Christian
>
>
> Am 08.07.2011 14:39, schrieb Florent BENOIT:
>
> Hi,
>>
>> One example about the "reliable" stuff is that we should include
>> "recovery".
>> For example the correlation map used to match JMS replies is stored in
>> memory [1]
>> 341 Exchange exchange = correlationMap.remove(**correlationId);
>> 342 if (exchange == null) {
>> 343 LOG.log(Level.WARNING, "Could not correlate message with
>> correlationId " + correlationId);
>> 344 return;
>> 345 }
>>
>>
>> So, if the JVM of the client is restarted, we will loose any replies as we
>> won't know how to match the reply.
>> Also, there is no JTA used with the current JMS transport. It means that
>> we can loose data or to get some messages twice or so one.
>>
>> So even by using ActiveMQ with the messages being stored on the disk, this
>> won't work after a restart.
>>
>> [1] :
>> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
>> src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
>> view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup>
>>
>> Regards,
>>
>> Florent
>>
>> On 07/08/2011 02:25 PM, Benson Margulies wrote:
>>
>>> I'm confused. If you use AMQ configured for reliable storage on disk,
>>> how do you lose things with the existing CXF transport?
>>>
>>> On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT<Fl...@ow2.org>
>>> wrote:
>>>
>>>> Hi CXF guys,
>>>>
>>>> I would like to introduce a new CXF transport that we've developed and
>>>> that
>>>> could be contributed back to the CXF community. It is called "Reliable
>>>> JMS
>>>> transport"
>>>>
>>>> When this transport has been designed, the goal was to have a reliable
>>>> transport that we could called "Enterprise Transport" as we wanted to
>>>> use
>>>> transactions and JMS by using containers like Java EE EJB or Spring MDP
>>>> (we
>>>> support both). We don't want to loose any requests or answers and we
>>>> want to
>>>> avoid waiting threads. This transport has not been designed from scratch
>>>> as
>>>> it is using the JMS layer and share some classes with the current CXF
>>>> JMS
>>>> transport but there are some differences between them. But we couldn't
>>>> change the current transport as the design is not the same.
>>>>
>>>> First, let me give you details about this transport and why it's
>>>> different
>>>> from the current JMS CXF transport.
>>>>
>>>> The current CXF JMS transport is not reliable. For example, if you
>>>> restart a
>>>> client or a server you may loose some requests/answers. This is because
>>>> the
>>>> mechanism that is used is keeping data in memory. So after a JVM crash,
>>>> all
>>>> the data are lost.
>>>> Also, for this new transport, we wanted to guarantee the delivery so it
>>>> is
>>>> using transactions. (A transaction manager is then required).
>>>> As said before, we wanted to avoid the use of threads waiting for an
>>>> answer.
>>>> If there are 100 requests, we don't want 100 threads waiting their
>>>> answer.
>>>> This is because we can use either EJB MDB or Spring MDP to handle the
>>>> answer. In this way, resources are allocated only if an answer is
>>>> handled
>>>> and not during all the waiting time. So the number of threads is
>>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're
>>>> based
>>>> on existing patterns.
>>>>
>>>> Here is a link to the documentation of this transport and pictures that
>>>> are
>>>> illustrating this solution :
>>>> http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/**
>>>> ReliableJMS_Transport_CXF<http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF>
>>>> This illustrates how the
>>>>
>>>> And the errors handling that is working with all kind of JVM crash :
>>>> http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/**
>>>> ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-**
>>>> simple-failure-english.png<http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png>
>>>>
>>>> There are integration tests included in this transport that are launched
>>>> through our continous integration tool on http://bamboo.ow2.org
>>>> For now, they're using JOnAS as Java EE server as we need a JTA manager
>>>> and
>>>> we test both EJB MDB and Spring MDP providers.
>>>>
>>>> To sum up, is there an interest in CXF to integrate this transport ?
>>>> What
>>>> kind of changes need to be done, etc.
>>>> Also I hope to get some feedback about this protocol.
>>>>
>>>> Regards,
>>>>
>>>> Florent
>>>>
>>>>
>>>>
>>>>
>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by "Guillaume Sauthier (Objectweb)" <gu...@objectweb.org>.
I'm sorry guys, I just noticed that we did give you an URL where you can
take/look the code :)
Here is the websvn URL:
http://websvn.ow2.org/listing.php?repname=jonas&path=%2Fsub-projects%2Fcxf-reliable-jms-transport%2F
And here the SVN URL:
svn://svn.forge.objectweb.org/svnroot/jonas/sub-projects/
cxf-reliable-jms-transport/trunk
As it was introduced in OW2 JOnAS and that our preferred license in LGPL,
all the current sources are in LGPL, but if the CXF community is interested
in this contribution, I foresee no issues of changing the license to ASL2.
Thanks for your comments
--G
2011/7/8 Guillaume Sauthier (Objectweb) <gu...@objectweb.org>
> Hi
>
> I've helped to do this new transport, so let me add my 2 cents ;)
>
> If the message exchange pattern is one way, there is no problem as no one
> expects an answer.
> But that new transport support the request-response pattern.
>
> That means that we have to manage reliabiilty of the call end to end, from
> the client that initiates the call, to the code that process the answer,
> through the endpoint.
>
> If you look at the global picture:
>
> http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-english.png
>
> you'll notice that the client is split in 2 parts: the initiator (initiates
> the call) and the handler (process the result).
>
> We don't use the JAXWS AsyncHandler API because it is tightly coupled to
> the execution context of the client initiator: maybe the handler has some
> ref to live objects that we cannot persist and/or recreate if the initiator
> JVM crashes.
>
> In order to bypass this issue, we had to tweak the jaxws development model
> a little bit:
> * on initiator side, we use the normal (synchronous) generated API, but the
> stub always returns null (as the call was synchronous, the answer is not
> there yet)
> * the initiator provides an AsynchHandler through the Spring application
> context, this handler will be notified when a response will be posted on the
> response queue. As this object is created from Spring beans, it is decoupled
> from the initiator execution context and can be safely used.
> * The request flow is quite normal: we define a <jaxws:client> on the
> client side, a <jaxws:endpoint> on the server side
> * But the response flow is different than what we could expect: the client
> also defines a <jaxws:endpoint> that will be invoked when JMS messages will
> be posted on the response queue.
>
> As everything is transactional, we have dead message queues, so that we
> never lost any messages.
>
> Hope that helps to understand this potential contribution.
>
> Thanks
> --Guillaume
>
>
>
> 2011/7/8 Christian Schneider <ch...@die-schneider.net>
>
>> Yes request / response correlation is definately a place where we
>> currently loose message when the client goes down.
>>
>> I think this is o big issue though as you typically only use request
>> response when you wait for the response. So normally you will even want the
>> responses to be lost when the client goes down. In the one way case we
>> should not loose messages as we can also use transactions.
>>
>> Still your JMS transport my be interesting. When doing the refactoring to
>> spring jms templates and message listener I also thought about making the
>> transport more asynchronous but never really did it.
>> So I would like to compare your implementation with the current one in
>> cxf.
>>
>> I would not like to have both though. If your transport is more suitable
>> we should throw the other away. In any case we should only have one JMS
>> transport.
>>
>> Christian
>>
>>
>> Am 08.07.2011 14:39, schrieb Florent BENOIT:
>>
>> Hi,
>>>
>>> One example about the "reliable" stuff is that we should include
>>> "recovery".
>>> For example the correlation map used to match JMS replies is stored in
>>> memory [1]
>>> 341 Exchange exchange = correlationMap.remove(**correlationId);
>>> 342 if (exchange == null) {
>>> 343 LOG.log(Level.WARNING, "Could not correlate message with
>>> correlationId " + correlationId);
>>> 344 return;
>>> 345 }
>>>
>>>
>>> So, if the JVM of the client is restarted, we will loose any replies as
>>> we won't know how to match the reply.
>>> Also, there is no JTA used with the current JMS transport. It means that
>>> we can loose data or to get some messages twice or so one.
>>>
>>> So even by using ActiveMQ with the messages being stored on the disk,
>>> this won't work after a restart.
>>>
>>> [1] :
>>> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
>>> src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
>>> view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup>
>>>
>>> Regards,
>>>
>>> Florent
>>>
>>> On 07/08/2011 02:25 PM, Benson Margulies wrote:
>>>
>>>> I'm confused. If you use AMQ configured for reliable storage on disk,
>>>> how do you lose things with the existing CXF transport?
>>>>
>>>> On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT<Fl...@ow2.org>
>>>> wrote:
>>>>
>>>>> Hi CXF guys,
>>>>>
>>>>> I would like to introduce a new CXF transport that we've developed and
>>>>> that
>>>>> could be contributed back to the CXF community. It is called "Reliable
>>>>> JMS
>>>>> transport"
>>>>>
>>>>> When this transport has been designed, the goal was to have a reliable
>>>>> transport that we could called "Enterprise Transport" as we wanted to
>>>>> use
>>>>> transactions and JMS by using containers like Java EE EJB or Spring MDP
>>>>> (we
>>>>> support both). We don't want to loose any requests or answers and we
>>>>> want to
>>>>> avoid waiting threads. This transport has not been designed from
>>>>> scratch as
>>>>> it is using the JMS layer and share some classes with the current CXF
>>>>> JMS
>>>>> transport but there are some differences between them. But we couldn't
>>>>> change the current transport as the design is not the same.
>>>>>
>>>>> First, let me give you details about this transport and why it's
>>>>> different
>>>>> from the current JMS CXF transport.
>>>>>
>>>>> The current CXF JMS transport is not reliable. For example, if you
>>>>> restart a
>>>>> client or a server you may loose some requests/answers. This is because
>>>>> the
>>>>> mechanism that is used is keeping data in memory. So after a JVM crash,
>>>>> all
>>>>> the data are lost.
>>>>> Also, for this new transport, we wanted to guarantee the delivery so it
>>>>> is
>>>>> using transactions. (A transaction manager is then required).
>>>>> As said before, we wanted to avoid the use of threads waiting for an
>>>>> answer.
>>>>> If there are 100 requests, we don't want 100 threads waiting their
>>>>> answer.
>>>>> This is because we can use either EJB MDB or Spring MDP to handle the
>>>>> answer. In this way, resources are allocated only if an answer is
>>>>> handled
>>>>> and not during all the waiting time. So the number of threads is
>>>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're
>>>>> based
>>>>> on existing patterns.
>>>>>
>>>>> Here is a link to the documentation of this transport and pictures that
>>>>> are
>>>>> illustrating this solution :
>>>>> http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/**
>>>>> ReliableJMS_Transport_CXF<http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF>
>>>>> This illustrates how the
>>>>>
>>>>> And the errors handling that is working with all kind of JVM crash :
>>>>> http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/**
>>>>> ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-**
>>>>> simple-failure-english.png<http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png>
>>>>>
>>>>> There are integration tests included in this transport that are
>>>>> launched
>>>>> through our continous integration tool on http://bamboo.ow2.org
>>>>> For now, they're using JOnAS as Java EE server as we need a JTA manager
>>>>> and
>>>>> we test both EJB MDB and Spring MDP providers.
>>>>>
>>>>> To sum up, is there an interest in CXF to integrate this transport ?
>>>>> What
>>>>> kind of changes need to be done, etc.
>>>>> Also I hope to get some feedback about this protocol.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Florent
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by "Guillaume Sauthier (Objectweb)" <gu...@objectweb.org>.
Hi
I've helped to do this new transport, so let me add my 2 cents ;)
If the message exchange pattern is one way, there is no problem as no one
expects an answer.
But that new transport support the request-response pattern.
That means that we have to manage reliabiilty of the call end to end, from
the client that initiates the call, to the code that process the answer,
through the endpoint.
If you look at the global picture:
http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-english.png
you'll notice that the client is split in 2 parts: the initiator (initiates
the call) and the handler (process the result).
We don't use the JAXWS AsyncHandler API because it is tightly coupled to the
execution context of the client initiator: maybe the handler has some ref to
live objects that we cannot persist and/or recreate if the initiator JVM
crashes.
In order to bypass this issue, we had to tweak the jaxws development model a
little bit:
* on initiator side, we use the normal (synchronous) generated API, but the
stub always returns null (as the call was synchronous, the answer is not
there yet)
* the initiator provides an AsynchHandler through the Spring application
context, this handler will be notified when a response will be posted on the
response queue. As this object is created from Spring beans, it is decoupled
from the initiator execution context and can be safely used.
* The request flow is quite normal: we define a <jaxws:client> on the client
side, a <jaxws:endpoint> on the server side
* But the response flow is different than what we could expect: the client
also defines a <jaxws:endpoint> that will be invoked when JMS messages will
be posted on the response queue.
As everything is transactional, we have dead message queues, so that we
never lost any messages.
Hope that helps to understand this potential contribution.
Thanks
--Guillaume
2011/7/8 Christian Schneider <ch...@die-schneider.net>
> Yes request / response correlation is definately a place where we currently
> loose message when the client goes down.
>
> I think this is o big issue though as you typically only use request
> response when you wait for the response. So normally you will even want the
> responses to be lost when the client goes down. In the one way case we
> should not loose messages as we can also use transactions.
>
> Still your JMS transport my be interesting. When doing the refactoring to
> spring jms templates and message listener I also thought about making the
> transport more asynchronous but never really did it.
> So I would like to compare your implementation with the current one in cxf.
>
> I would not like to have both though. If your transport is more suitable we
> should throw the other away. In any case we should only have one JMS
> transport.
>
> Christian
>
>
> Am 08.07.2011 14:39, schrieb Florent BENOIT:
>
> Hi,
>>
>> One example about the "reliable" stuff is that we should include
>> "recovery".
>> For example the correlation map used to match JMS replies is stored in
>> memory [1]
>> 341 Exchange exchange = correlationMap.remove(**correlationId);
>> 342 if (exchange == null) {
>> 343 LOG.log(Level.WARNING, "Could not correlate message with
>> correlationId " + correlationId);
>> 344 return;
>> 345 }
>>
>>
>> So, if the JVM of the client is restarted, we will loose any replies as we
>> won't know how to match the reply.
>> Also, there is no JTA used with the current JMS transport. It means that
>> we can loose data or to get some messages twice or so one.
>>
>> So even by using ActiveMQ with the messages being stored on the disk, this
>> won't work after a restart.
>>
>> [1] :
>> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
>> src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
>> view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup>
>>
>> Regards,
>>
>> Florent
>>
>> On 07/08/2011 02:25 PM, Benson Margulies wrote:
>>
>>> I'm confused. If you use AMQ configured for reliable storage on disk,
>>> how do you lose things with the existing CXF transport?
>>>
>>> On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT<Fl...@ow2.org>
>>> wrote:
>>>
>>>> Hi CXF guys,
>>>>
>>>> I would like to introduce a new CXF transport that we've developed and
>>>> that
>>>> could be contributed back to the CXF community. It is called "Reliable
>>>> JMS
>>>> transport"
>>>>
>>>> When this transport has been designed, the goal was to have a reliable
>>>> transport that we could called "Enterprise Transport" as we wanted to
>>>> use
>>>> transactions and JMS by using containers like Java EE EJB or Spring MDP
>>>> (we
>>>> support both). We don't want to loose any requests or answers and we
>>>> want to
>>>> avoid waiting threads. This transport has not been designed from scratch
>>>> as
>>>> it is using the JMS layer and share some classes with the current CXF
>>>> JMS
>>>> transport but there are some differences between them. But we couldn't
>>>> change the current transport as the design is not the same.
>>>>
>>>> First, let me give you details about this transport and why it's
>>>> different
>>>> from the current JMS CXF transport.
>>>>
>>>> The current CXF JMS transport is not reliable. For example, if you
>>>> restart a
>>>> client or a server you may loose some requests/answers. This is because
>>>> the
>>>> mechanism that is used is keeping data in memory. So after a JVM crash,
>>>> all
>>>> the data are lost.
>>>> Also, for this new transport, we wanted to guarantee the delivery so it
>>>> is
>>>> using transactions. (A transaction manager is then required).
>>>> As said before, we wanted to avoid the use of threads waiting for an
>>>> answer.
>>>> If there are 100 requests, we don't want 100 threads waiting their
>>>> answer.
>>>> This is because we can use either EJB MDB or Spring MDP to handle the
>>>> answer. In this way, resources are allocated only if an answer is
>>>> handled
>>>> and not during all the waiting time. So the number of threads is
>>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're
>>>> based
>>>> on existing patterns.
>>>>
>>>> Here is a link to the documentation of this transport and pictures that
>>>> are
>>>> illustrating this solution :
>>>> http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/**
>>>> ReliableJMS_Transport_CXF<http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF>
>>>> This illustrates how the
>>>>
>>>> And the errors handling that is working with all kind of JVM crash :
>>>> http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/**
>>>> ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-**
>>>> simple-failure-english.png<http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png>
>>>>
>>>> There are integration tests included in this transport that are launched
>>>> through our continous integration tool on http://bamboo.ow2.org
>>>> For now, they're using JOnAS as Java EE server as we need a JTA manager
>>>> and
>>>> we test both EJB MDB and Spring MDP providers.
>>>>
>>>> To sum up, is there an interest in CXF to integrate this transport ?
>>>> What
>>>> kind of changes need to be done, etc.
>>>> Also I hope to get some feedback about this protocol.
>>>>
>>>> Regards,
>>>>
>>>> Florent
>>>>
>>>>
>>>>
>>>>
>>
>>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by Christian Schneider <ch...@die-schneider.net>.
Yes request / response correlation is definately a place where we
currently loose message when the client goes down.
I think this is o big issue though as you typically only use request
response when you wait for the response. So normally you will even want
the responses to be lost when the client goes down. In the one way case
we should not loose messages as we can also use transactions.
Still your JMS transport my be interesting. When doing the refactoring
to spring jms templates and message listener I also thought about making
the transport more asynchronous but never really did it.
So I would like to compare your implementation with the current one in cxf.
I would not like to have both though. If your transport is more suitable
we should throw the other away. In any case we should only have one JMS
transport.
Christian
Am 08.07.2011 14:39, schrieb Florent BENOIT:
> Hi,
>
> One example about the "reliable" stuff is that we should include
> "recovery".
> For example the correlation map used to match JMS replies is stored in
> memory [1]
> 341 Exchange exchange = correlationMap.remove(correlationId);
> 342 if (exchange == null) {
> 343 LOG.log(Level.WARNING, "Could not correlate message with
> correlationId " + correlationId);
> 344 return;
> 345 }
>
>
> So, if the JVM of the client is restarted, we will loose any replies
> as we won't know how to match the reply.
> Also, there is no JTA used with the current JMS transport. It means
> that we can loose data or to get some messages twice or so one.
>
> So even by using ActiveMQ with the messages being stored on the disk,
> this won't work after a restart.
>
> [1] :
> http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup
>
>
> Regards,
>
> Florent
>
> On 07/08/2011 02:25 PM, Benson Margulies wrote:
>> I'm confused. If you use AMQ configured for reliable storage on disk,
>> how do you lose things with the existing CXF transport?
>>
>> On Fri, Jul 8, 2011 at 8:23 AM, Florent
>> BENOIT<Fl...@ow2.org> wrote:
>>> Hi CXF guys,
>>>
>>> I would like to introduce a new CXF transport that we've developed
>>> and that
>>> could be contributed back to the CXF community. It is called
>>> "Reliable JMS
>>> transport"
>>>
>>> When this transport has been designed, the goal was to have a reliable
>>> transport that we could called "Enterprise Transport" as we wanted
>>> to use
>>> transactions and JMS by using containers like Java EE EJB or Spring
>>> MDP (we
>>> support both). We don't want to loose any requests or answers and we
>>> want to
>>> avoid waiting threads. This transport has not been designed from
>>> scratch as
>>> it is using the JMS layer and share some classes with the current
>>> CXF JMS
>>> transport but there are some differences between them. But we couldn't
>>> change the current transport as the design is not the same.
>>>
>>> First, let me give you details about this transport and why it's
>>> different
>>> from the current JMS CXF transport.
>>>
>>> The current CXF JMS transport is not reliable. For example, if you
>>> restart a
>>> client or a server you may loose some requests/answers. This is
>>> because the
>>> mechanism that is used is keeping data in memory. So after a JVM
>>> crash, all
>>> the data are lost.
>>> Also, for this new transport, we wanted to guarantee the delivery so
>>> it is
>>> using transactions. (A transaction manager is then required).
>>> As said before, we wanted to avoid the use of threads waiting for an
>>> answer.
>>> If there are 100 requests, we don't want 100 threads waiting their
>>> answer.
>>> This is because we can use either EJB MDB or Spring MDP to handle the
>>> answer. In this way, resources are allocated only if an answer is
>>> handled
>>> and not during all the waiting time. So the number of threads is
>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're
>>> based
>>> on existing patterns.
>>>
>>> Here is a link to the documentation of this transport and pictures
>>> that are
>>> illustrating this solution :
>>> http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
>>> This illustrates how the
>>>
>>> And the errors handling that is working with all kind of JVM crash :
>>> http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png
>>>
>>>
>>> There are integration tests included in this transport that are
>>> launched
>>> through our continous integration tool on http://bamboo.ow2.org
>>> For now, they're using JOnAS as Java EE server as we need a JTA
>>> manager and
>>> we test both EJB MDB and Spring MDP providers.
>>>
>>> To sum up, is there an interest in CXF to integrate this transport ?
>>> What
>>> kind of changes need to be done, etc.
>>> Also I hope to get some feedback about this protocol.
>>>
>>> Regards,
>>>
>>> Florent
>>>
>>>
>>>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by Florent BENOIT <Fl...@ow2.org>.
Hi,
One example about the "reliable" stuff is that we should include "recovery".
For example the correlation map used to match JMS replies is stored in
memory [1]
341 Exchange exchange = correlationMap.remove(correlationId);
342 if (exchange == null) {
343 LOG.log(Level.WARNING, "Could not correlate message with
correlationId " + correlationId);
344 return;
345 }
So, if the JVM of the client is restarted, we will loose any replies as
we won't know how to match the reply.
Also, there is no JTA used with the current JMS transport. It means that
we can loose data or to get some messages twice or so one.
So even by using ActiveMQ with the messages being stored on the disk,
this won't work after a restart.
[1] :
http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup
Regards,
Florent
On 07/08/2011 02:25 PM, Benson Margulies wrote:
> I'm confused. If you use AMQ configured for reliable storage on disk,
> how do you lose things with the existing CXF transport?
>
> On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT<Fl...@ow2.org> wrote:
>
>> Hi CXF guys,
>>
>> I would like to introduce a new CXF transport that we've developed and that
>> could be contributed back to the CXF community. It is called "Reliable JMS
>> transport"
>>
>> When this transport has been designed, the goal was to have a reliable
>> transport that we could called "Enterprise Transport" as we wanted to use
>> transactions and JMS by using containers like Java EE EJB or Spring MDP (we
>> support both). We don't want to loose any requests or answers and we want to
>> avoid waiting threads. This transport has not been designed from scratch as
>> it is using the JMS layer and share some classes with the current CXF JMS
>> transport but there are some differences between them. But we couldn't
>> change the current transport as the design is not the same.
>>
>> First, let me give you details about this transport and why it's different
>> from the current JMS CXF transport.
>>
>> The current CXF JMS transport is not reliable. For example, if you restart a
>> client or a server you may loose some requests/answers. This is because the
>> mechanism that is used is keeping data in memory. So after a JVM crash, all
>> the data are lost.
>> Also, for this new transport, we wanted to guarantee the delivery so it is
>> using transactions. (A transaction manager is then required).
>> As said before, we wanted to avoid the use of threads waiting for an answer.
>> If there are 100 requests, we don't want 100 threads waiting their answer.
>> This is because we can use either EJB MDB or Spring MDP to handle the
>> answer. In this way, resources are allocated only if an answer is handled
>> and not during all the waiting time. So the number of threads is
>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're based
>> on existing patterns.
>>
>> Here is a link to the documentation of this transport and pictures that are
>> illustrating this solution :
>> http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
>> This illustrates how the
>>
>> And the errors handling that is working with all kind of JVM crash :
>> http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png
>>
>> There are integration tests included in this transport that are launched
>> through our continous integration tool on http://bamboo.ow2.org
>> For now, they're using JOnAS as Java EE server as we need a JTA manager and
>> we test both EJB MDB and Spring MDP providers.
>>
>> To sum up, is there an interest in CXF to integrate this transport ? What
>> kind of changes need to be done, etc.
>> Also I hope to get some feedback about this protocol.
>>
>> Regards,
>>
>> Florent
>>
>>
>>
>>
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Posted by Benson Margulies <bi...@gmail.com>.
I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?
On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT <Fl...@ow2.org> wrote:
> Hi CXF guys,
>
> I would like to introduce a new CXF transport that we've developed and that
> could be contributed back to the CXF community. It is called "Reliable JMS
> transport"
>
> When this transport has been designed, the goal was to have a reliable
> transport that we could called "Enterprise Transport" as we wanted to use
> transactions and JMS by using containers like Java EE EJB or Spring MDP (we
> support both). We don't want to loose any requests or answers and we want to
> avoid waiting threads. This transport has not been designed from scratch as
> it is using the JMS layer and share some classes with the current CXF JMS
> transport but there are some differences between them. But we couldn't
> change the current transport as the design is not the same.
>
> First, let me give you details about this transport and why it's different
> from the current JMS CXF transport.
>
> The current CXF JMS transport is not reliable. For example, if you restart a
> client or a server you may loose some requests/answers. This is because the
> mechanism that is used is keeping data in memory. So after a JVM crash, all
> the data are lost.
> Also, for this new transport, we wanted to guarantee the delivery so it is
> using transactions. (A transaction manager is then required).
> As said before, we wanted to avoid the use of threads waiting for an answer.
> If there are 100 requests, we don't want 100 threads waiting their answer.
> This is because we can use either EJB MDB or Spring MDP to handle the
> answer. In this way, resources are allocated only if an answer is handled
> and not during all the waiting time. So the number of threads is
> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're based
> on existing patterns.
>
> Here is a link to the documentation of this transport and pictures that are
> illustrating this solution :
> http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
> This illustrates how the
>
> And the errors handling that is working with all kind of JVM crash :
> http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png
>
> There are integration tests included in this transport that are launched
> through our continous integration tool on http://bamboo.ow2.org
> For now, they're using JOnAS as Java EE server as we need a JTA manager and
> we test both EJB MDB and Spring MDP providers.
>
> To sum up, is there an interest in CXF to integrate this transport ? What
> kind of changes need to be done, etc.
> Also I hope to get some feedback about this protocol.
>
> Regards,
>
> Florent
>
>
>