cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent BENOIT <Florent.Ben...@ow2.org>
Subject Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Date Fri, 08 Jul 2011 12:39:27 GMT
     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<Florent.Benoit@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
>>
>>
>>
>>      


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