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 23:16:46 GMT
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 <jason@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" <dkulp@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 <jason@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" <chris@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
>>
>>

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