cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <ja...@pellcorp.com>
Subject Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Date Fri, 05 Dec 2014 03:42:11 GMT
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 <jason@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 <jason@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 <jason@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 <jason@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" <jason@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" <chris@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
>>>>>>
>>>>>>
>>>
>>
>

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