You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jason Pell <ja...@pellcorp.com> on 2014/12/04 18:09:17 UTC
Cxf 2.7 JMS destination change what happens when checked exception is
thrown from service impl
Hi,
I would like to change the existing behavior of JMS destination to NOT
rollback the transaction if a checked exception is encountered.
https://issues.apache.org/jira/browse/CXF-6136
Christian suggested I post an email to this list to give everyone an
opportunity to agree or disagree with my proposed changes.
Currently if a transaction manager is registered (even just a JMS
transaction manager) and an exception is thrown by an impl method the JMS
message will be rolled back.
There is currently no distinction made. Even if I throw a business soap
fault its still going to roll back the message.
I would like to add code to JMS Destination to no longer propagate checked
exceptions which will result in the delivery of a soap fault response to
the JMS reply queue.
Christian has suggested we could make this change without a backwards
compatible config entry in JMSConfiguration. I am happy to add a config
entry to maintain legacy behavior..
Thoughts?
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Hi Christian,
I updated the JMS Configuration page on confluence based on my experience
with enabling transaction support for JMS. I added a note about being able
to register a JMS Transaction Manager and that for 2.7 a transaction
manager must be registered to get transactions in addition to
sessionTransacted.
Can you have a quick look and make sure my comments are accurate
On Sat, Dec 6, 2014 at 4:42 AM, Jason Pell <ja...@pellcorp.com> wrote:
> OK I am going to revert my changes, add a config property to
> JMSConfiguration to optionally disable exception propagation.
>
> The existing behavior will remain the default potential bugs and all.
>
> Cxf 3.0 won't need that property as that's the default anyway
> On 06/12/2014 3:45 AM, "Daniel Kulp" <dk...@apache.org> wrote:
>
>>
>> Honestly, I have no idea on the transaction stuff in the JMS transport.
>> I’m really not sure of the use cases where it’s needed or working correctly
>> or as desired.
>>
>> For example, if the soap message isn’t valid and we cannot parse it, why
>> should it be rolled back and retried? We’re not going to be able to parse
>> it again next time either. If there are issues trying to send the
>> response back to the client, sure. I can see that. But most of the
>> others seem to cause more problems.
>>
>>
>> Dan
>>
>>
>> > On Dec 5, 2014, at 6:59 AM, Jason Pell <ja...@pellcorp.com> wrote:
>> >
>> > I think I could probably live with no rollbacks at all even inside a
>> > transaction. That is certainly more consistent than cxf 2.x. Maybe we
>> > don't even need to change anything in cxf 3.
>> >
>> > Perhaps we can change cxf 2.x so it behaves same way. At least make it a
>> > config option.
>> >
>> > I could live with that as I agree with you the requestor can resend if
>> > needed and its cleaner than the dead letter queue.
>> >
>> > I might take another stab at disabling all exception propagation in JMS
>> > Destination. I can then ignore the session matching issue and move on
>> with
>> > my life :-)
>> >
>> > Be interested to get some background from Dan on why its there though...
>> > On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net>
>> > wrote:
>> >
>> >> For request/ reply:
>> >> If you have a transaction then the message will be rolled back if cxf
>> >> dies. In all other cases cxf should send back a reply with the eventual
>> >> exception as a soap fault.
>> >> I think this behaviour is what you expect as a requestor.
>> >>
>> >> As there are always some cases where the requestor will get no reply
>> or a
>> >> fault the requestor always has to include some code to resend the
>> request.
>> >>
>> >> I am not against using optional rollbacks but we have to make sure we
>> do
>> >> not create unwanted behaviour.
>> >>
>> >> Maybe we should have a switch for to decide if rollbacks should happen
>> in
>> >> request/reply. On the other hand I try to have as few switches as
>> possible.
>> >> Every thing that is done optionally increases test effort and makes it
>> >> harder to document / explain how it works. So we should be sure it
>> makes
>> >> sense.
>> >>
>> >> Christian
>> >>
>> >> On 05.12.2014 11:29, Jason Pell wrote:
>> >>
>> >>> I would like the option of enabling roll backs for runtime exceptions
>> in
>> >>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a
>> error in
>> >>> middle of process where by the reply is never delivered but the
>> request
>> >>> has
>> >>> disappeared so essentially there is no evidence of wother message. At
>> >>> least
>> >>> with the transaction even if it's just the spring JMS transaction
>> manager
>> >>> both messages will be delivered or neither will.
>> >>> On 05/12/2014 8:44 PM, "Christian Schneider" <chris@die-schneider.net
>> >
>> >>> wrote:
>> >>>
>> >>>
>> >> --
>> >> Christian Schneider
>> >> http://www.liquid-reality.de
>> >>
>> >> Open Source Architect
>> >> http://www.talend.com
>> >>
>> >>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
OK I am going to revert my changes, add a config property to
JMSConfiguration to optionally disable exception propagation.
The existing behavior will remain the default potential bugs and all.
Cxf 3.0 won't need that property as that's the default anyway
On 06/12/2014 3:45 AM, "Daniel Kulp" <dk...@apache.org> wrote:
>
> Honestly, I have no idea on the transaction stuff in the JMS transport.
> I’m really not sure of the use cases where it’s needed or working correctly
> or as desired.
>
> For example, if the soap message isn’t valid and we cannot parse it, why
> should it be rolled back and retried? We’re not going to be able to parse
> it again next time either. If there are issues trying to send the
> response back to the client, sure. I can see that. But most of the
> others seem to cause more problems.
>
>
> Dan
>
>
> > On Dec 5, 2014, at 6:59 AM, Jason Pell <ja...@pellcorp.com> wrote:
> >
> > I think I could probably live with no rollbacks at all even inside a
> > transaction. That is certainly more consistent than cxf 2.x. Maybe we
> > don't even need to change anything in cxf 3.
> >
> > Perhaps we can change cxf 2.x so it behaves same way. At least make it a
> > config option.
> >
> > I could live with that as I agree with you the requestor can resend if
> > needed and its cleaner than the dead letter queue.
> >
> > I might take another stab at disabling all exception propagation in JMS
> > Destination. I can then ignore the session matching issue and move on
> with
> > my life :-)
> >
> > Be interested to get some background from Dan on why its there though...
> > On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net>
> > wrote:
> >
> >> For request/ reply:
> >> If you have a transaction then the message will be rolled back if cxf
> >> dies. In all other cases cxf should send back a reply with the eventual
> >> exception as a soap fault.
> >> I think this behaviour is what you expect as a requestor.
> >>
> >> As there are always some cases where the requestor will get no reply or
> a
> >> fault the requestor always has to include some code to resend the
> request.
> >>
> >> I am not against using optional rollbacks but we have to make sure we do
> >> not create unwanted behaviour.
> >>
> >> Maybe we should have a switch for to decide if rollbacks should happen
> in
> >> request/reply. On the other hand I try to have as few switches as
> possible.
> >> Every thing that is done optionally increases test effort and makes it
> >> harder to document / explain how it works. So we should be sure it makes
> >> sense.
> >>
> >> Christian
> >>
> >> On 05.12.2014 11:29, Jason Pell wrote:
> >>
> >>> I would like the option of enabling roll backs for runtime exceptions
> in
> >>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a
> error in
> >>> middle of process where by the reply is never delivered but the request
> >>> has
> >>> disappeared so essentially there is no evidence of wother message. At
> >>> least
> >>> with the transaction even if it's just the spring JMS transaction
> manager
> >>> both messages will be delivered or neither will.
> >>> On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
> >>> wrote:
> >>>
> >>>
> >> --
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> http://www.talend.com
> >>
> >>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Posted by Daniel Kulp <dk...@apache.org>.
Honestly, I have no idea on the transaction stuff in the JMS transport. I’m really not sure of the use cases where it’s needed or working correctly or as desired.
For example, if the soap message isn’t valid and we cannot parse it, why should it be rolled back and retried? We’re not going to be able to parse it again next time either. If there are issues trying to send the response back to the client, sure. I can see that. But most of the others seem to cause more problems.
Dan
> On Dec 5, 2014, at 6:59 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
> I think I could probably live with no rollbacks at all even inside a
> transaction. That is certainly more consistent than cxf 2.x. Maybe we
> don't even need to change anything in cxf 3.
>
> Perhaps we can change cxf 2.x so it behaves same way. At least make it a
> config option.
>
> I could live with that as I agree with you the requestor can resend if
> needed and its cleaner than the dead letter queue.
>
> I might take another stab at disabling all exception propagation in JMS
> Destination. I can then ignore the session matching issue and move on with
> my life :-)
>
> Be interested to get some background from Dan on why its there though...
> On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>> For request/ reply:
>> If you have a transaction then the message will be rolled back if cxf
>> dies. In all other cases cxf should send back a reply with the eventual
>> exception as a soap fault.
>> I think this behaviour is what you expect as a requestor.
>>
>> As there are always some cases where the requestor will get no reply or a
>> fault the requestor always has to include some code to resend the request.
>>
>> I am not against using optional rollbacks but we have to make sure we do
>> not create unwanted behaviour.
>>
>> Maybe we should have a switch for to decide if rollbacks should happen in
>> request/reply. On the other hand I try to have as few switches as possible.
>> Every thing that is done optionally increases test effort and makes it
>> harder to document / explain how it works. So we should be sure it makes
>> sense.
>>
>> Christian
>>
>> On 05.12.2014 11:29, Jason Pell wrote:
>>
>>> I would like the option of enabling roll backs for runtime exceptions in
>>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in
>>> middle of process where by the reply is never delivered but the request
>>> has
>>> disappeared so essentially there is no evidence of wother message. At
>>> least
>>> with the transaction even if it's just the spring JMS transaction manager
>>> both messages will be delivered or neither will.
>>> On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
>>> wrote:
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
I think I could probably live with no rollbacks at all even inside a
transaction. That is certainly more consistent than cxf 2.x. Maybe we
don't even need to change anything in cxf 3.
Perhaps we can change cxf 2.x so it behaves same way. At least make it a
config option.
I could live with that as I agree with you the requestor can resend if
needed and its cleaner than the dead letter queue.
I might take another stab at disabling all exception propagation in JMS
Destination. I can then ignore the session matching issue and move on with
my life :-)
Be interested to get some background from Dan on why its there though...
On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> For request/ reply:
> If you have a transaction then the message will be rolled back if cxf
> dies. In all other cases cxf should send back a reply with the eventual
> exception as a soap fault.
> I think this behaviour is what you expect as a requestor.
>
> As there are always some cases where the requestor will get no reply or a
> fault the requestor always has to include some code to resend the request.
>
> I am not against using optional rollbacks but we have to make sure we do
> not create unwanted behaviour.
>
> Maybe we should have a switch for to decide if rollbacks should happen in
> request/reply. On the other hand I try to have as few switches as possible.
> Every thing that is done optionally increases test effort and makes it
> harder to document / explain how it works. So we should be sure it makes
> sense.
>
> Christian
>
> On 05.12.2014 11:29, Jason Pell wrote:
>
>> I would like the option of enabling roll backs for runtime exceptions in
>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in
>> middle of process where by the reply is never delivered but the request
>> has
>> disappeared so essentially there is no evidence of wother message. At
>> least
>> with the transaction even if it's just the spring JMS transaction manager
>> both messages will be delivered or neither will.
>> On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
No problem. I will review the cxf 3 stuff early 2015
On 05/12/2014 9:46 PM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> For request/ reply:
> If you have a transaction then the message will be rolled back if cxf
> dies. In all other cases cxf should send back a reply with the eventual
> exception as a soap fault.
> I think this behaviour is what you expect as a requestor.
>
> As there are always some cases where the requestor will get no reply or a
> fault the requestor always has to include some code to resend the request.
>
> I am not against using optional rollbacks but we have to make sure we do
> not create unwanted behaviour.
>
> Maybe we should have a switch for to decide if rollbacks should happen in
> request/reply. On the other hand I try to have as few switches as possible.
> Every thing that is done optionally increases test effort and makes it
> harder to document / explain how it works. So we should be sure it makes
> sense.
>
> Christian
>
> On 05.12.2014 11:29, Jason Pell wrote:
>
>> I would like the option of enabling roll backs for runtime exceptions in
>> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in
>> middle of process where by the reply is never delivered but the request
>> has
>> disappeared so essentially there is no evidence of wother message. At
>> least
>> with the transaction even if it's just the spring JMS transaction manager
>> both messages will be delivered or neither will.
>> On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked exception
is thrown from service impl
Posted by Christian Schneider <ch...@die-schneider.net>.
For request/ reply:
If you have a transaction then the message will be rolled back if cxf
dies. In all other cases cxf should send back a reply with the eventual
exception as a soap fault.
I think this behaviour is what you expect as a requestor.
As there are always some cases where the requestor will get no reply or
a fault the requestor always has to include some code to resend the request.
I am not against using optional rollbacks but we have to make sure we do
not create unwanted behaviour.
Maybe we should have a switch for to decide if rollbacks should happen
in request/reply. On the other hand I try to have as few switches as
possible. Every thing that is done optionally increases test effort and
makes it harder to document / explain how it works. So we should be sure
it makes sense.
Christian
On 05.12.2014 11:29, Jason Pell wrote:
> I would like the option of enabling roll backs for runtime exceptions in
> cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in
> middle of process where by the reply is never delivered but the request has
> disappeared so essentially there is no evidence of wother message. At least
> with the transaction even if it's just the spring JMS transaction manager
> both messages will be delivered or neither will.
> On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
I would like the option of enabling roll backs for runtime exceptions in
cxf 3 when I eventually upgrade. Does cxf 3 at least cater for a error in
middle of process where by the reply is never delivered but the request has
disappeared so essentially there is no evidence of wother message. At least
with the transaction even if it's just the spring JMS transaction manager
both messages will be delivered or neither will.
On 05/12/2014 8:44 PM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> Honestly I am not sure about the code in getRollbackRuntimeException (in
> your code). Maybe Dan knows. He added the code.
> I was never sure how well the transactions in cxf 2 really worked.
>
> I just checked the code in CXF 3.
> There I decided to completely avoid rolling back transactions for
> request/reply. I think the reason is that the caller expects a reply.
> The issue is that if you roll back then the message broker will retry a
> number of times and then move the message to a dead letter queue.
> So in this case the caller would get no reply at all.
>
> This is why I decided that a request/reply will always return the
> exception to the caller. I have not found any materials on the net if this
> is the right choice.
> So we should discuss this here.
>
> Christian
>
>
> On 05.12.2014 07:33, Jason Pell wrote:
>
>> Hi Christian,
>>
>> I have added a test case to my github branch which demonstrates the
>> session
>> issue and fails as a result. The session in the session holder is the
>> same as the session passed into the onMessage method.
>>
>> In the jms systests:
>>
>> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerSameSessionTest
>>
>> Currently when it executes, a soap fault is returned immediately. What
>> actually should be happening is a rollback of the message occurs, and the
>> GreeterImplWithTransaction then flips the boolean flag
>> and returns a valid result.
>>
>> I have debugged this test and it fails to perform the rollback because of
>> this test:
>>
>> boolean trans = resourceHolder == null ||
>> !resourceHolder.containsSession(session);
>>
>> The resourceHolder does contain the session. Where as for all other test
>> cases (and my own which use both websphere mq and activemq), the sessions
>> do not match.
>>
>> I need to understand exactly why the resource holder having the session
>> means trans = false....
>>
>> Thanks
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked exception
is thrown from service impl
Posted by Christian Schneider <ch...@die-schneider.net>.
Honestly I am not sure about the code in getRollbackRuntimeException (in
your code). Maybe Dan knows. He added the code.
I was never sure how well the transactions in cxf 2 really worked.
I just checked the code in CXF 3.
There I decided to completely avoid rolling back transactions for
request/reply. I think the reason is that the caller expects a reply.
The issue is that if you roll back then the message broker will retry a
number of times and then move the message to a dead letter queue.
So in this case the caller would get no reply at all.
This is why I decided that a request/reply will always return the
exception to the caller. I have not found any materials on the net if
this is the right choice.
So we should discuss this here.
Christian
On 05.12.2014 07:33, Jason Pell wrote:
> Hi Christian,
>
> I have added a test case to my github branch which demonstrates the session
> issue and fails as a result. The session in the session holder is the
> same as the session passed into the onMessage method.
>
> In the jms systests:
>
> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerSameSessionTest
>
> Currently when it executes, a soap fault is returned immediately. What
> actually should be happening is a rollback of the message occurs, and the
> GreeterImplWithTransaction then flips the boolean flag
> and returns a valid result.
>
> I have debugged this test and it fails to perform the rollback because of
> this test:
>
> boolean trans = resourceHolder == null ||
> !resourceHolder.containsSession(session);
>
> The resourceHolder does contain the session. Where as for all other test
> cases (and my own which use both websphere mq and activemq), the sessions
> do not match.
>
> I need to understand exactly why the resource holder having the session
> means trans = false....
>
> Thanks
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Hi Christian,
I have added a test case to my github branch which demonstrates the session
issue and fails as a result. The session in the session holder is the
same as the session passed into the onMessage method.
In the jms systests:
org.apache.cxf.systest.jms.tx.JMSTransactionClientServerSameSessionTest
Currently when it executes, a soap fault is returned immediately. What
actually should be happening is a rollback of the message occurs, and the
GreeterImplWithTransaction then flips the boolean flag
and returns a valid result.
I have debugged this test and it fails to perform the rollback because of
this test:
boolean trans = resourceHolder == null ||
!resourceHolder.containsSession(session);
The resourceHolder does contain the session. Where as for all other test
cases (and my own which use both websphere mq and activemq), the sessions
do not match.
I need to understand exactly why the resource holder having the session
means trans = false....
Thanks
On Fri, Dec 5, 2014 at 2:42 PM, Jason Pell <ja...@pellcorp.com> wrote:
> Would be interested in your feedback regarding the change.
>
>
> https://github.com/pellcorp/apache-cxf/compare/apache:2.7.x-fixes...cxf6136_jms_ex_rollback?expand=1
>
>
>
> On Fri, Dec 5, 2014 at 1:53 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Never mind, think I figured it out.
>>
>> Another question I have, is should the JMSDestination sendExchange be
>> aborted if we are going to rollback anyway? As it stands, the message gets
>> sent to the MOM and then immediately backed out, which seems kind of silly.
>>
>>
>>
>> On Fri, Dec 5, 2014 at 12:42 PM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> Ok - in my local tests with both websphere mq and active mq, the trans
>>> test appears to be doing the right thing, but I am unsure why. I don't
>>> understand why the sessions are not the same.
>>>
>>> However when I am debugging the
>>> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerTest in
>>> cxf-systests-transport-jm the trans test is false because the sessions
>>> match.
>>>
>>> I know I must be missing something, and I will continue to debug it to
>>> see if I can figure it out, but perhaps someone might have some insight to
>>> assist me
>>>
>>> On Fri, Dec 5, 2014 at 11:20 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>>
>>>> Hi Christian,
>>>>
>>>> While writing a test case for the transaction case for request /
>>>> response I came across something else in the code I am confused about.
>>>>
>>>> The JMSDestination has a check of the following:
>>>>
>>>> boolean trans = resourceHolder == null ||
>>>> !resourceHolder.containsSession(session);
>>>>
>>>> So if the resourceHolder is not found or the resource holder does not
>>>> have the session, then there is no transaction. Is this correct?
>>>>
>>>> I would have thought the opposite would have been true:
>>>>
>>>> boolean trans = resourceHolder != null &&
>>>> resourceHolder.containsSession(session);
>>>>
>>>> Can you comment on this?
>>>>
>>>>
>>>> On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>>>
>>>>> Very annoyed with myself that I did not check the transaction support
>>>>> for request response till now. Was on my list of todos. Now I am going to
>>>>> have to depend on 2.7.15 snapahot.
>>>>>
>>>>> I need guaranteed delivery even for request response as my client is
>>>>> not expecting to have to retry and the message needs to survive a server
>>>>> crash or db issue.
>>>>>
>>>>> I am not going to use xa transactions though. Will be enough to use
>>>>> good old jms transaction manager support.
>>>>> On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>>>>
>>>>>> I check that the exception cause is instanceof Exception and not
>>>>>> propogate. Otherwise the old functionality applies.
>>>>>> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
>>>>>> wrote:
>>>>>>
>>>>>>> I think one thing to consider is handling of java.lang.Error. These
>>>>>>> are not of type Exception and not of type RuntimeException. As they are not
>>>>>>> expected a Rollback may be apropriate but I am not sure.
>>>>>>>
>>>>>>> As far as I can remember the reason why I did not implement a more
>>>>>>> sophisticated behaviour till now is that I never actually used transactions
>>>>>>> for Request/Reply.
>>>>>>> In one way messaging transactions are essential as the caller has to
>>>>>>> be sure that messages do not get lost.
>>>>>>> In request/reply there is always someone on the other side listening
>>>>>>> for the reply. If no reply comes he can and probably will retry. So there
>>>>>>> is much less pressure to use transactions at all.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to change the existing behavior of JMS destination to
>>>>>>>> NOT
>>>>>>>> rollback the transaction if a checked exception is encountered.
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>>>>>
>>>>>>>> Christian suggested I post an email to this list to give everyone an
>>>>>>>> opportunity to agree or disagree with my proposed changes.
>>>>>>>>
>>>>>>>> Currently if a transaction manager is registered (even just a JMS
>>>>>>>> transaction manager) and an exception is thrown by an impl method
>>>>>>>> the JMS
>>>>>>>> message will be rolled back.
>>>>>>>>
>>>>>>>> There is currently no distinction made. Even if I throw a business
>>>>>>>> soap
>>>>>>>> fault its still going to roll back the message.
>>>>>>>>
>>>>>>>> I would like to add code to JMS Destination to no longer propagate
>>>>>>>> checked
>>>>>>>> exceptions which will result in the delivery of a soap fault
>>>>>>>> response to
>>>>>>>> the JMS reply queue.
>>>>>>>>
>>>>>>>> Christian has suggested we could make this change without a
>>>>>>>> backwards
>>>>>>>> compatible config entry in JMSConfiguration. I am happy to add a
>>>>>>>> config
>>>>>>>> entry to maintain legacy behavior..
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christian Schneider
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>> Open Source Architect
>>>>>>> http://www.talend.com
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Would be interested in your feedback regarding the change.
https://github.com/pellcorp/apache-cxf/compare/apache:2.7.x-fixes...cxf6136_jms_ex_rollback?expand=1
On Fri, Dec 5, 2014 at 1:53 PM, Jason Pell <ja...@pellcorp.com> wrote:
> Never mind, think I figured it out.
>
> Another question I have, is should the JMSDestination sendExchange be
> aborted if we are going to rollback anyway? As it stands, the message gets
> sent to the MOM and then immediately backed out, which seems kind of silly.
>
>
>
> On Fri, Dec 5, 2014 at 12:42 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Ok - in my local tests with both websphere mq and active mq, the trans
>> test appears to be doing the right thing, but I am unsure why. I don't
>> understand why the sessions are not the same.
>>
>> However when I am debugging the
>> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerTest in
>> cxf-systests-transport-jm the trans test is false because the sessions
>> match.
>>
>> I know I must be missing something, and I will continue to debug it to
>> see if I can figure it out, but perhaps someone might have some insight to
>> assist me
>>
>> On Fri, Dec 5, 2014 at 11:20 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> Hi Christian,
>>>
>>> While writing a test case for the transaction case for request /
>>> response I came across something else in the code I am confused about.
>>>
>>> The JMSDestination has a check of the following:
>>>
>>> boolean trans = resourceHolder == null ||
>>> !resourceHolder.containsSession(session);
>>>
>>> So if the resourceHolder is not found or the resource holder does not
>>> have the session, then there is no transaction. Is this correct?
>>>
>>> I would have thought the opposite would have been true:
>>>
>>> boolean trans = resourceHolder != null &&
>>> resourceHolder.containsSession(session);
>>>
>>> Can you comment on this?
>>>
>>>
>>> On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>>
>>>> Very annoyed with myself that I did not check the transaction support
>>>> for request response till now. Was on my list of todos. Now I am going to
>>>> have to depend on 2.7.15 snapahot.
>>>>
>>>> I need guaranteed delivery even for request response as my client is
>>>> not expecting to have to retry and the message needs to survive a server
>>>> crash or db issue.
>>>>
>>>> I am not going to use xa transactions though. Will be enough to use
>>>> good old jms transaction manager support.
>>>> On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>>>
>>>>> I check that the exception cause is instanceof Exception and not
>>>>> propogate. Otherwise the old functionality applies.
>>>>> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
>>>>> wrote:
>>>>>
>>>>>> I think one thing to consider is handling of java.lang.Error. These
>>>>>> are not of type Exception and not of type RuntimeException. As they are not
>>>>>> expected a Rollback may be apropriate but I am not sure.
>>>>>>
>>>>>> As far as I can remember the reason why I did not implement a more
>>>>>> sophisticated behaviour till now is that I never actually used transactions
>>>>>> for Request/Reply.
>>>>>> In one way messaging transactions are essential as the caller has to
>>>>>> be sure that messages do not get lost.
>>>>>> In request/reply there is always someone on the other side listening
>>>>>> for the reply. If no reply comes he can and probably will retry. So there
>>>>>> is much less pressure to use transactions at all.
>>>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to change the existing behavior of JMS destination to
>>>>>>> NOT
>>>>>>> rollback the transaction if a checked exception is encountered.
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>>>>
>>>>>>> Christian suggested I post an email to this list to give everyone an
>>>>>>> opportunity to agree or disagree with my proposed changes.
>>>>>>>
>>>>>>> Currently if a transaction manager is registered (even just a JMS
>>>>>>> transaction manager) and an exception is thrown by an impl method
>>>>>>> the JMS
>>>>>>> message will be rolled back.
>>>>>>>
>>>>>>> There is currently no distinction made. Even if I throw a business
>>>>>>> soap
>>>>>>> fault its still going to roll back the message.
>>>>>>>
>>>>>>> I would like to add code to JMS Destination to no longer propagate
>>>>>>> checked
>>>>>>> exceptions which will result in the delivery of a soap fault
>>>>>>> response to
>>>>>>> the JMS reply queue.
>>>>>>>
>>>>>>> Christian has suggested we could make this change without a backwards
>>>>>>> compatible config entry in JMSConfiguration. I am happy to add a
>>>>>>> config
>>>>>>> entry to maintain legacy behavior..
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> http://www.talend.com
>>>>>>
>>>>>>
>>>
>>
>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Never mind, think I figured it out.
Another question I have, is should the JMSDestination sendExchange be
aborted if we are going to rollback anyway? As it stands, the message gets
sent to the MOM and then immediately backed out, which seems kind of silly.
On Fri, Dec 5, 2014 at 12:42 PM, Jason Pell <ja...@pellcorp.com> wrote:
> Ok - in my local tests with both websphere mq and active mq, the trans
> test appears to be doing the right thing, but I am unsure why. I don't
> understand why the sessions are not the same.
>
> However when I am debugging the
> org.apache.cxf.systest.jms.tx.JMSTransactionClientServerTest in
> cxf-systests-transport-jm the trans test is false because the sessions
> match.
>
> I know I must be missing something, and I will continue to debug it to see
> if I can figure it out, but perhaps someone might have some insight to
> assist me
>
> On Fri, Dec 5, 2014 at 11:20 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Hi Christian,
>>
>> While writing a test case for the transaction case for request / response
>> I came across something else in the code I am confused about.
>>
>> The JMSDestination has a check of the following:
>>
>> boolean trans = resourceHolder == null ||
>> !resourceHolder.containsSession(session);
>>
>> So if the resourceHolder is not found or the resource holder does not
>> have the session, then there is no transaction. Is this correct?
>>
>> I would have thought the opposite would have been true:
>>
>> boolean trans = resourceHolder != null &&
>> resourceHolder.containsSession(session);
>>
>> Can you comment on this?
>>
>>
>> On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <ja...@pellcorp.com> wrote:
>>
>>> Very annoyed with myself that I did not check the transaction support
>>> for request response till now. Was on my list of todos. Now I am going to
>>> have to depend on 2.7.15 snapahot.
>>>
>>> I need guaranteed delivery even for request response as my client is not
>>> expecting to have to retry and the message needs to survive a server crash
>>> or db issue.
>>>
>>> I am not going to use xa transactions though. Will be enough to use good
>>> old jms transaction manager support.
>>> On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>>
>>>> I check that the exception cause is instanceof Exception and not
>>>> propogate. Otherwise the old functionality applies.
>>>> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
>>>> wrote:
>>>>
>>>>> I think one thing to consider is handling of java.lang.Error. These
>>>>> are not of type Exception and not of type RuntimeException. As they are not
>>>>> expected a Rollback may be apropriate but I am not sure.
>>>>>
>>>>> As far as I can remember the reason why I did not implement a more
>>>>> sophisticated behaviour till now is that I never actually used transactions
>>>>> for Request/Reply.
>>>>> In one way messaging transactions are essential as the caller has to
>>>>> be sure that messages do not get lost.
>>>>> In request/reply there is always someone on the other side listening
>>>>> for the reply. If no reply comes he can and probably will retry. So there
>>>>> is much less pressure to use transactions at all.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to change the existing behavior of JMS destination to NOT
>>>>>> rollback the transaction if a checked exception is encountered.
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>>>
>>>>>> Christian suggested I post an email to this list to give everyone an
>>>>>> opportunity to agree or disagree with my proposed changes.
>>>>>>
>>>>>> Currently if a transaction manager is registered (even just a JMS
>>>>>> transaction manager) and an exception is thrown by an impl method the
>>>>>> JMS
>>>>>> message will be rolled back.
>>>>>>
>>>>>> There is currently no distinction made. Even if I throw a business
>>>>>> soap
>>>>>> fault its still going to roll back the message.
>>>>>>
>>>>>> I would like to add code to JMS Destination to no longer propagate
>>>>>> checked
>>>>>> exceptions which will result in the delivery of a soap fault response
>>>>>> to
>>>>>> the JMS reply queue.
>>>>>>
>>>>>> Christian has suggested we could make this change without a backwards
>>>>>> compatible config entry in JMSConfiguration. I am happy to add a
>>>>>> config
>>>>>> entry to maintain legacy behavior..
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> http://www.talend.com
>>>>>
>>>>>
>>
>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Ok - in my local tests with both websphere mq and active mq, the trans test
appears to be doing the right thing, but I am unsure why. I don't
understand why the sessions are not the same.
However when I am debugging the
org.apache.cxf.systest.jms.tx.JMSTransactionClientServerTest in
cxf-systests-transport-jm the trans test is false because the sessions
match.
I know I must be missing something, and I will continue to debug it to see
if I can figure it out, but perhaps someone might have some insight to
assist me
On Fri, Dec 5, 2014 at 11:20 AM, Jason Pell <ja...@pellcorp.com> wrote:
> Hi Christian,
>
> While writing a test case for the transaction case for request / response
> I came across something else in the code I am confused about.
>
> The JMSDestination has a check of the following:
>
> boolean trans = resourceHolder == null ||
> !resourceHolder.containsSession(session);
>
> So if the resourceHolder is not found or the resource holder does not have
> the session, then there is no transaction. Is this correct?
>
> I would have thought the opposite would have been true:
>
> boolean trans = resourceHolder != null &&
> resourceHolder.containsSession(session);
>
> Can you comment on this?
>
>
> On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <ja...@pellcorp.com> wrote:
>
>> Very annoyed with myself that I did not check the transaction support for
>> request response till now. Was on my list of todos. Now I am going to have
>> to depend on 2.7.15 snapahot.
>>
>> I need guaranteed delivery even for request response as my client is not
>> expecting to have to retry and the message needs to survive a server crash
>> or db issue.
>>
>> I am not going to use xa transactions though. Will be enough to use good
>> old jms transaction manager support.
>> On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>>
>>> I check that the exception cause is instanceof Exception and not
>>> propogate. Otherwise the old functionality applies.
>>> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
>>> wrote:
>>>
>>>> I think one thing to consider is handling of java.lang.Error. These are
>>>> not of type Exception and not of type RuntimeException. As they are not
>>>> expected a Rollback may be apropriate but I am not sure.
>>>>
>>>> As far as I can remember the reason why I did not implement a more
>>>> sophisticated behaviour till now is that I never actually used transactions
>>>> for Request/Reply.
>>>> In one way messaging transactions are essential as the caller has to be
>>>> sure that messages do not get lost.
>>>> In request/reply there is always someone on the other side listening
>>>> for the reply. If no reply comes he can and probably will retry. So there
>>>> is much less pressure to use transactions at all.
>>>>
>>>> Christian
>>>>
>>>>
>>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to change the existing behavior of JMS destination to NOT
>>>>> rollback the transaction if a checked exception is encountered.
>>>>>
>>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>>
>>>>> Christian suggested I post an email to this list to give everyone an
>>>>> opportunity to agree or disagree with my proposed changes.
>>>>>
>>>>> Currently if a transaction manager is registered (even just a JMS
>>>>> transaction manager) and an exception is thrown by an impl method the
>>>>> JMS
>>>>> message will be rolled back.
>>>>>
>>>>> There is currently no distinction made. Even if I throw a business soap
>>>>> fault its still going to roll back the message.
>>>>>
>>>>> I would like to add code to JMS Destination to no longer propagate
>>>>> checked
>>>>> exceptions which will result in the delivery of a soap fault response
>>>>> to
>>>>> the JMS reply queue.
>>>>>
>>>>> Christian has suggested we could make this change without a backwards
>>>>> compatible config entry in JMSConfiguration. I am happy to add a config
>>>>> entry to maintain legacy behavior..
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>>
>>>> --
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> http://www.talend.com
>>>>
>>>>
>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Hi Christian,
While writing a test case for the transaction case for request / response I
came across something else in the code I am confused about.
The JMSDestination has a check of the following:
boolean trans = resourceHolder == null ||
!resourceHolder.containsSession(session);
So if the resourceHolder is not found or the resource holder does not have
the session, then there is no transaction. Is this correct?
I would have thought the opposite would have been true:
boolean trans = resourceHolder != null &&
resourceHolder.containsSession(session);
Can you comment on this?
On Fri, Dec 5, 2014 at 9:26 AM, Jason Pell <ja...@pellcorp.com> wrote:
> Very annoyed with myself that I did not check the transaction support for
> request response till now. Was on my list of todos. Now I am going to have
> to depend on 2.7.15 snapahot.
>
> I need guaranteed delivery even for request response as my client is not
> expecting to have to retry and the message needs to survive a server crash
> or db issue.
>
> I am not going to use xa transactions though. Will be enough to use good
> old jms transaction manager support.
> On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
>
>> I check that the exception cause is instanceof Exception and not
>> propogate. Otherwise the old functionality applies.
>> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
>> wrote:
>>
>>> I think one thing to consider is handling of java.lang.Error. These are
>>> not of type Exception and not of type RuntimeException. As they are not
>>> expected a Rollback may be apropriate but I am not sure.
>>>
>>> As far as I can remember the reason why I did not implement a more
>>> sophisticated behaviour till now is that I never actually used transactions
>>> for Request/Reply.
>>> In one way messaging transactions are essential as the caller has to be
>>> sure that messages do not get lost.
>>> In request/reply there is always someone on the other side listening for
>>> the reply. If no reply comes he can and probably will retry. So there is
>>> much less pressure to use transactions at all.
>>>
>>> Christian
>>>
>>>
>>> On 04.12.2014 18:09, Jason Pell wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to change the existing behavior of JMS destination to NOT
>>>> rollback the transaction if a checked exception is encountered.
>>>>
>>>> https://issues.apache.org/jira/browse/CXF-6136
>>>>
>>>> Christian suggested I post an email to this list to give everyone an
>>>> opportunity to agree or disagree with my proposed changes.
>>>>
>>>> Currently if a transaction manager is registered (even just a JMS
>>>> transaction manager) and an exception is thrown by an impl method the
>>>> JMS
>>>> message will be rolled back.
>>>>
>>>> There is currently no distinction made. Even if I throw a business soap
>>>> fault its still going to roll back the message.
>>>>
>>>> I would like to add code to JMS Destination to no longer propagate
>>>> checked
>>>> exceptions which will result in the delivery of a soap fault response to
>>>> the JMS reply queue.
>>>>
>>>> Christian has suggested we could make this change without a backwards
>>>> compatible config entry in JMSConfiguration. I am happy to add a config
>>>> entry to maintain legacy behavior..
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Very annoyed with myself that I did not check the transaction support for
request response till now. Was on my list of todos. Now I am going to have
to depend on 2.7.15 snapahot.
I need guaranteed delivery even for request response as my client is not
expecting to have to retry and the message needs to survive a server crash
or db issue.
I am not going to use xa transactions though. Will be enough to use good
old jms transaction manager support.
On 05/12/2014 9:13 AM, "Jason Pell" <ja...@pellcorp.com> wrote:
> I check that the exception cause is instanceof Exception and not
> propogate. Otherwise the old functionality applies.
> On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
> wrote:
>
>> I think one thing to consider is handling of java.lang.Error. These are
>> not of type Exception and not of type RuntimeException. As they are not
>> expected a Rollback may be apropriate but I am not sure.
>>
>> As far as I can remember the reason why I did not implement a more
>> sophisticated behaviour till now is that I never actually used transactions
>> for Request/Reply.
>> In one way messaging transactions are essential as the caller has to be
>> sure that messages do not get lost.
>> In request/reply there is always someone on the other side listening for
>> the reply. If no reply comes he can and probably will retry. So there is
>> much less pressure to use transactions at all.
>>
>> Christian
>>
>>
>> On 04.12.2014 18:09, Jason Pell wrote:
>>
>>> Hi,
>>>
>>> I would like to change the existing behavior of JMS destination to NOT
>>> rollback the transaction if a checked exception is encountered.
>>>
>>> https://issues.apache.org/jira/browse/CXF-6136
>>>
>>> Christian suggested I post an email to this list to give everyone an
>>> opportunity to agree or disagree with my proposed changes.
>>>
>>> Currently if a transaction manager is registered (even just a JMS
>>> transaction manager) and an exception is thrown by an impl method the JMS
>>> message will be rolled back.
>>>
>>> There is currently no distinction made. Even if I throw a business soap
>>> fault its still going to roll back the message.
>>>
>>> I would like to add code to JMS Destination to no longer propagate
>>> checked
>>> exceptions which will result in the delivery of a soap fault response to
>>> the JMS reply queue.
>>>
>>> Christian has suggested we could make this change without a backwards
>>> compatible config entry in JMSConfiguration. I am happy to add a config
>>> entry to maintain legacy behavior..
>>>
>>> Thoughts?
>>>
>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
I check that the exception cause is instanceof Exception and not propogate.
Otherwise the old functionality applies.
On 05/12/2014 8:41 AM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> I think one thing to consider is handling of java.lang.Error. These are
> not of type Exception and not of type RuntimeException. As they are not
> expected a Rollback may be apropriate but I am not sure.
>
> As far as I can remember the reason why I did not implement a more
> sophisticated behaviour till now is that I never actually used transactions
> for Request/Reply.
> In one way messaging transactions are essential as the caller has to be
> sure that messages do not get lost.
> In request/reply there is always someone on the other side listening for
> the reply. If no reply comes he can and probably will retry. So there is
> much less pressure to use transactions at all.
>
> Christian
>
>
> On 04.12.2014 18:09, Jason Pell wrote:
>
>> Hi,
>>
>> I would like to change the existing behavior of JMS destination to NOT
>> rollback the transaction if a checked exception is encountered.
>>
>> https://issues.apache.org/jira/browse/CXF-6136
>>
>> Christian suggested I post an email to this list to give everyone an
>> opportunity to agree or disagree with my proposed changes.
>>
>> Currently if a transaction manager is registered (even just a JMS
>> transaction manager) and an exception is thrown by an impl method the JMS
>> message will be rolled back.
>>
>> There is currently no distinction made. Even if I throw a business soap
>> fault its still going to roll back the message.
>>
>> I would like to add code to JMS Destination to no longer propagate checked
>> exceptions which will result in the delivery of a soap fault response to
>> the JMS reply queue.
>>
>> Christian has suggested we could make this change without a backwards
>> compatible config entry in JMSConfiguration. I am happy to add a config
>> entry to maintain legacy behavior..
>>
>> Thoughts?
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked exception
is thrown from service impl
Posted by Christian Schneider <ch...@die-schneider.net>.
I think one thing to consider is handling of java.lang.Error. These are
not of type Exception and not of type RuntimeException. As they are not
expected a Rollback may be apropriate but I am not sure.
As far as I can remember the reason why I did not implement a more
sophisticated behaviour till now is that I never actually used
transactions for Request/Reply.
In one way messaging transactions are essential as the caller has to be
sure that messages do not get lost.
In request/reply there is always someone on the other side listening for
the reply. If no reply comes he can and probably will retry. So there is
much less pressure to use transactions at all.
Christian
On 04.12.2014 18:09, Jason Pell wrote:
> Hi,
>
> I would like to change the existing behavior of JMS destination to NOT
> rollback the transaction if a checked exception is encountered.
>
> https://issues.apache.org/jira/browse/CXF-6136
>
> Christian suggested I post an email to this list to give everyone an
> opportunity to agree or disagree with my proposed changes.
>
> Currently if a transaction manager is registered (even just a JMS
> transaction manager) and an exception is thrown by an impl method the JMS
> message will be rolled back.
>
> There is currently no distinction made. Even if I throw a business soap
> fault its still going to roll back the message.
>
> I would like to add code to JMS Destination to no longer propagate checked
> exceptions which will result in the delivery of a soap fault response to
> the JMS reply queue.
>
> Christian has suggested we could make this change without a backwards
> compatible config entry in JMSConfiguration. I am happy to add a config
> entry to maintain legacy behavior..
>
> Thoughts?
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Cxf 2.7 JMS destination change what happens when checked
exception is thrown from service impl
Posted by Jason Pell <ja...@pellcorp.com>.
Not at the moment :-)
On 05/12/2014 6:09 AM, "Daniel Kulp" <dk...@apache.org> wrote:
>
> > On Dec 4, 2014, at 12:09 PM, Jason Pell <ja...@pellcorp.com> wrote:
> >
> > Hi,
> >
> > I would like to change the existing behavior of JMS destination to NOT
> > rollback the transaction if a checked exception is encountered.
>
> Honestly, this is how I thought it DID work. Checked exceptions are
> expected conditions and valid responses.
>
> Dan
>
>
>
> >
> > https://issues.apache.org/jira/browse/CXF-6136
> >
> > Christian suggested I post an email to this list to give everyone an
> > opportunity to agree or disagree with my proposed changes.
> >
> > Currently if a transaction manager is registered (even just a JMS
> > transaction manager) and an exception is thrown by an impl method the JMS
> > message will be rolled back.
> >
> > There is currently no distinction made. Even if I throw a business soap
> > fault its still going to roll back the message.
> >
> > I would like to add code to JMS Destination to no longer propagate
> checked
> > exceptions which will result in the delivery of a soap fault response to
> > the JMS reply queue.
> >
> > Christian has suggested we could make this change without a backwards
> > compatible config entry in JMSConfiguration. I am happy to add a config
> > entry to maintain legacy behavior..
> >
> > Thoughts?
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 4, 2014, at 12:09 PM, Jason Pell <ja...@pellcorp.com> wrote:
>
> Hi,
>
> I would like to change the existing behavior of JMS destination to NOT
> rollback the transaction if a checked exception is encountered.
Honestly, this is how I thought it DID work. Checked exceptions are expected conditions and valid responses.
Dan
>
> https://issues.apache.org/jira/browse/CXF-6136
>
> Christian suggested I post an email to this list to give everyone an
> opportunity to agree or disagree with my proposed changes.
>
> Currently if a transaction manager is registered (even just a JMS
> transaction manager) and an exception is thrown by an impl method the JMS
> message will be rolled back.
>
> There is currently no distinction made. Even if I throw a business soap
> fault its still going to roll back the message.
>
> I would like to add code to JMS Destination to no longer propagate checked
> exceptions which will result in the delivery of a soap fault response to
> the JMS reply queue.
>
> Christian has suggested we could make this change without a backwards
> compatible config entry in JMSConfiguration. I am happy to add a config
> entry to maintain legacy behavior..
>
> Thoughts?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com