cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Date Fri, 08 Jul 2011 12:25:22 GMT
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 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 :
> This illustrates how the
> And the errors handling that is working with all kind of JVM crash :
> 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

View raw message