You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/04/10 10:38:46 UTC
JTA support for JMS Transport in CXF 3.0
Hi All,
I am currently working on the transaction support (resource local and
JTA) for the JMS transport in CXF 3.
In a chat with Dan we found that it is not fully clear what we expect
from the transaction support. So I will do a coarse design here on the
list and hope to get some feedback on
what you expect and would like to see.
The general principle on kind of "container" managed transaction support
is to open a transaction when a message is received. Then the message is
processed inside the transaction. If an exception happens in the
processing the transaction is rolled back and the JMS server tries some
redeliveries. If these all fail the message goes to the dead letter
queue. If the processing runs without an exception the transaction and
so the message will be committed.
Service side:
- Support transactions only for One Way messaging. I think for request
reply there is always a client on the other side who can retry when a
message is lost and the client also wants some feedback about errors on
the server side.
- For one way exchanges I propose to roll back on any exceptions as it
is the simplest case. We might also support to permanently fail a
message on things like invalid xml as this will probably also fail the
next time. It is difficult to correctly specify when to roll back and
when to fail in this case.
- I tested the low level MessageListenerContainer I created with
resource local and JTA transactions. JTA only seems to work if I use a
polling approach. I am not sure if this is expected.
Client Side:
- No special handling on conduit side
- If the user uses a JCA Pooling Connection Factory the session would
automatically take part in any user transactions. For one way messaging
this is probably a good thing. For request reply this is rather not what
we want as the message would only be sent after the commit. As the
conduit waits for the reply the message then would never be sent out and
we run into a timeout.
I would be happy to hear from you what you would expect from transaction
support and what you think about the ideas formulated here. If any of
you has first hand experience with JMS transactions (especially JTA) I
would also like to hear from your experiences.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
RE: JTA support for JMS Transport in CXF 3.0
Posted by Andrei Shakirin <as...@talend.com>.
Hi Christian,
Some comments inline:
> -----Original Message-----
> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
> Christian Schneider
> Sent: Donnerstag, 10. April 2014 10:39
> To: CXF Dev
> Subject: JTA support for JMS Transport in CXF 3.0
>
> Hi All,
>
> I am currently working on the transaction support (resource local and
> JTA) for the JMS transport in CXF 3.
>
> In a chat with Dan we found that it is not fully clear what we expect from the
> transaction support. So I will do a coarse design here on the list and hope to get
> some feedback on what you expect and would like to see.
>
> The general principle on kind of "container" managed transaction support is to
> open a transaction when a message is received. Then the message is processed
> inside the transaction. If an exception happens in the processing the transaction
> is rolled back and the JMS server tries some redeliveries. If these all fail the
> message goes to the dead letter queue. If the processing runs without an
> exception the transaction and so the message will be committed.
Generally speaking transactions can be used on receiving and on sending sides: if transaction is successfully committed, all receiving messages are acknowledged and sending messages are sent.
Basically it is possible to have some use case for transaction in case of sending messages as well:
- if user sends correlated messages in some different queues/topics and would like to keep this atomic
- if user sends message first and write some data in DB afterwards and would like to keep this atomic
But I agree that support transaction by receiving is the most important on the first step.
>
> Service side:
>
> - Support transactions only for One Way messaging. I think for request reply
> there is always a client on the other side who can retry when a message is lost
> and the client also wants some feedback about errors on the server side.
I see this the same as for previous topic: there are some uses cases for request-reply as well, but seems that one way is the most important for now.
In case of supporting transactions for message sending, user should be especially careful for request-reply: if he sends the message and then try to receive a reply to that message in the same transaction, the code will hang until timeout, because the send cannot take place until the transaction is committed.
> - For one way exchanges I propose to roll back on any exceptions as it is the
> simplest case. We might also support to permanently fail a message on things
> like invalid xml as this will probably also fail the next time. It is difficult to
> correctly specify when to roll back and when to fail in this case.
JEE supports following concept here:
1. All RuntimeException rollback the transaction
2. All checked exceptions declared with @ApplicationException(rollback=true) rollback the transaction
By default checked application exceptions do not rollback the transaction.
For CXF I see two possibilities on the first step:
a) rollback transaction on all exceptions at all (like Christian proposed)
b) rollback transaction on runtime exceptions only
I tend currently to (a) and support something like @ApplicationException(rollback=true) in the future.
WDYT?
> - I tested the low level MessageListenerContainer I created with resource local
> and JTA transactions. JTA only seems to work if I use a polling approach. I am
> not sure if this is expected.
I can look deeply on that.
>
> Client Side:
>
> - No special handling on conduit side
See the first comment: ok for now, can be extended for the future
> - If the user uses a JCA Pooling Connection Factory the session would
> automatically take part in any user transactions. For one way messaging this is
> probably a good thing. For request reply this is rather not what we want as the
> message would only be sent after the commit. As the conduit waits for the
> reply the message then would never be sent out and we run into a timeout.
Yep, I have pointed on this problem in second comment. Perhaps we should document this case and suggest to user to decouple sending and receiving the messages in case of using JCA Pooling Connection Factory.
I think we also be able to check this case in conduit and produce warning/error.
>
> I would be happy to hear from you what you would expect from transaction
> support and what you think about the ideas formulated here. If any of you has
> first hand experience with JMS transactions (especially JTA) I would also like to
> hear from your experiences.
>
> Christian
You did really amazing job with JMS, Christian!
Regards,
Andrei.
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
RE: JTA support for JMS Transport in CXF 3.0
Posted by Andrei Shakirin <as...@talend.com>.
Great job, Christian!
> -----Original Message-----
> From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of
> Christian Schneider
> Sent: Dienstag, 15. April 2014 10:54
> To: dev@cxf.apache.org
> Subject: Re: JTA support for JMS Transport in CXF 3.0
>
> I just finished the JTA support for one way messages. From my side we are
> ready for 3.0.0.
>
> Christian
>
> On 11.04.2014 12:43, Sergey Beryozkin wrote:
> > Hi Christian
> >
> > First of all: the way you've refactored the transport so far is
> > perfect :-).
> >
> > I'd only suggest that we try and release 3.0.0 first, may be do some
> > of your ideas in the next week or two (to get some initial transaction
> > support done) and immediately continue in 3.0.1. JAX-RS users can not
> > get a final 3.0.0 release and in May it will be the 1st anniversary of
> > JAX-RS 2.0 release, so I'm hoping they can see final 3.0.0 before May
> > :-)
> >
> > Sorry it is not about JMS, I agree we need to do it right with respect
> > to the transactions support, but hope we can split thos work across
> > consecutive releases
> >
> > Cheers, Sergey
> >
> >
> >
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
Re: JTA support for JMS Transport in CXF 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I just finished the JTA support for one way messages. From my side we
are ready for 3.0.0.
Christian
On 11.04.2014 12:43, Sergey Beryozkin wrote:
> Hi Christian
>
> First of all: the way you've refactored the transport so far is
> perfect :-).
>
> I'd only suggest that we try and release 3.0.0 first, may be do some
> of your ideas in the next week or two (to get some initial transaction
> support done) and immediately continue in 3.0.1. JAX-RS users can not
> get a final 3.0.0 release and in May it will be the 1st anniversary of
> JAX-RS 2.0 release, so I'm hoping they can see final 3.0.0 before May :-)
>
> Sorry it is not about JMS, I agree we need to do it right with respect
> to the transactions support, but hope we can split thos work across
> consecutive releases
>
> Cheers, Sergey
>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: JTA support for JMS Transport in CXF 3.0
Posted by Christian Schneider <ch...@die-schneider.net>.
I fully agree. The transaction support does not need to hold the 3.0.0
release. I will try to get the simple transaction support for one way
messages on server side into 3.0.0 but it would even be ok
to release right now.
Christian
Am 11.04.2014 12:43, schrieb Sergey Beryozkin:
> Hi Christian
>
> First of all: the way you've refactored the transport so far is
> perfect :-).
>
> I'd only suggest that we try and release 3.0.0 first, may be do some
> of your ideas in the next week or two (to get some initial transaction
> support done) and immediately continue in 3.0.1. JAX-RS users can not
> get a final 3.0.0 release and in May it will be the 1st anniversary of
> JAX-RS 2.0 release, so I'm hoping they can see final 3.0.0 before May :-)
>
> Sorry it is not about JMS, I agree we need to do it right with respect
> to the transactions support, but hope we can split thos work across
> consecutive releases
>
> Cheers, Sergey
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: JTA support for JMS Transport in CXF 3.0
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Christian
First of all: the way you've refactored the transport so far is perfect :-).
I'd only suggest that we try and release 3.0.0 first, may be do some of
your ideas in the next week or two (to get some initial transaction
support done) and immediately continue in 3.0.1. JAX-RS users can not
get a final 3.0.0 release and in May it will be the 1st anniversary of
JAX-RS 2.0 release, so I'm hoping they can see final 3.0.0 before May :-)
Sorry it is not about JMS, I agree we need to do it right with respect
to the transactions support, but hope we can split thos work across
consecutive releases
Cheers, Sergey
On 10/04/14 09:38, Christian Schneider wrote:
> Hi All,
>
> I am currently working on the transaction support (resource local and
> JTA) for the JMS transport in CXF 3.
>
> In a chat with Dan we found that it is not fully clear what we expect
> from the transaction support. So I will do a coarse design here on the
> list and hope to get some feedback on
> what you expect and would like to see.
>
> The general principle on kind of "container" managed transaction support
> is to open a transaction when a message is received. Then the message is
> processed inside the transaction. If an exception happens in the
> processing the transaction is rolled back and the JMS server tries some
> redeliveries. If these all fail the message goes to the dead letter
> queue. If the processing runs without an exception the transaction and
> so the message will be committed.
>
> Service side:
>
> - Support transactions only for One Way messaging. I think for request
> reply there is always a client on the other side who can retry when a
> message is lost and the client also wants some feedback about errors on
> the server side.
> - For one way exchanges I propose to roll back on any exceptions as it
> is the simplest case. We might also support to permanently fail a
> message on things like invalid xml as this will probably also fail the
> next time. It is difficult to correctly specify when to roll back and
> when to fail in this case.
> - I tested the low level MessageListenerContainer I created with
> resource local and JTA transactions. JTA only seems to work if I use a
> polling approach. I am not sure if this is expected.
>
> Client Side:
>
> - No special handling on conduit side
> - If the user uses a JCA Pooling Connection Factory the session would
> automatically take part in any user transactions. For one way messaging
> this is probably a good thing. For request reply this is rather not what
> we want as the message would only be sent after the commit. As the
> conduit waits for the reply the message then would never be sent out and
> we run into a timeout.
>
> I would be happy to hear from you what you would expect from transaction
> support and what you think about the ideas formulated here. If any of
> you has first hand experience with JMS transactions (especially JTA) I
> would also like to hear from your experiences.
>
> Christian
>
>
Re: JTA support for JMS Transport in CXF 3.0
Posted by Moritz Bechler <be...@agno3.eu>.
Hi Christian,
a few thoughts inline (not having looked at any of the code yet).
>
> I am currently working on the transaction support (resource local and
> JTA) for the JMS transport in CXF 3.
>
> In a chat with Dan we found that it is not fully clear what we expect
> from the transaction support. So I will do a coarse design here on the
> list and hope to get some feedback on
> what you expect and would like to see.
>
> The general principle on kind of "container" managed transaction support
> is to open a transaction when a message is received. Then the message is
> processed inside the transaction. If an exception happens in the
> processing the transaction is rolled back and the JMS server tries some
> redeliveries. If these all fail the message goes to the dead letter
> queue. If the processing runs without an exception the transaction and
> so the message will be committed.
>
> Service side:
>
> - Support transactions only for One Way messaging. I think for request
> reply there is always a client on the other side who can retry when a
> message is lost and the client also wants some feedback about errors on
> the server side.
This sounded interesting at first sight (to allow transparent
retry/failover) but propably will only lead to recv or transaction
timeout for most deployments.
Still, might be a nice to have to actually have a chance to get a
transaction allowing for rollback, if one were to make such experiments,
and have one started automatically. But then an error reply should be
committed in any case if not explicitly rolled back.
> - For one way exchanges I propose to roll back on any exceptions as it
> is the simplest case. We might also support to permanently fail a
> message on things like invalid xml as this will probably also fail the
> next time. It is difficult to correctly specify when to roll back and
> when to fail in this case.
Checked exceptions from the service code should imho qualify as
persistent errors (if they are even allowed).
CXF internal exceptions (xml/jaxb/validation errors) are indeed
difficult, whether these may be recoverable at all heavily depends on
the deployment so I agree this should be configurable.
The same holds for RuntimeExceptions thrown by service code. Some
implementations go with RuntimeException for rollback but this is still
very broad. Imho, this behavior should also be configurable (per service
if possible) plus there should be a custom exception type which always
triggers rollback.
> - I tested the low level MessageListenerContainer I created with
> resource local and JTA transactions. JTA only seems to work if I use a
> polling approach. I am not sure if this is expected.
I also ran into this with ActiveMQ, their consumer implementation does
not allow this. I asked about this on activemq-users quite a while ago
but got no response
(http://mail-archives.apache.org/mod_mbox/activemq-users/201308.mbox/%3C5218D907.3070602@agno3.eu%3E).
>
> Client Side:
>
> - No special handling on conduit side
> - If the user uses a JCA Pooling Connection Factory the session would
> automatically take part in any user transactions. For one way messaging
> this is probably a good thing. For request reply this is rather not what
> we want as the message would only be sent after the commit. As the
> conduit waits for the reply the message then would never be sent out and
> we run into a timeout.
Any chance to at least add something (callback?) that allows to commit
and restart a transaction at the right point? With implementations
closely following the spec, when using JTA the client session will
forcibly (if you do not create a second non-transacted
ConnectionFactory) be part of an active transaction (e.g. when calling a
service inside another service) so this will be necessary.
regards
Moritz
--
AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch