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<florent.ben...@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
