cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Cxf 2.7 JMS destination change what happens when checked exception is thrown from service impl
Date Fri, 05 Dec 2014 16:45:12 GMT

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
View raw message