cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Sauthier (Objectweb)" <>
Subject Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Date Tue, 12 Jul 2011 07:29:20 GMT
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:

And here the SVN URL:

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

2011/7/8 Guillaume Sauthier (Objectweb) <>

> 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:
> 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 <>
>> 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] :
>>> src/main/java/org/apache/cxf/**transport/jms/**
>>> 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<>
>>>>  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
>>>>> 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 :
>>>>> ReliableJMS_Transport_CXF<>
>>>>> This illustrates how the
>>>>> And the errors handling that is working with all kind of JVM crash :
>>>>> 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
>>>>> 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
>> Open Source Architect
>> Talend Application Integration Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message