Waldemar Szostak created CXF-6531:
-------------------------------------

             Summary: Exception-triggerring messages are re-delivered in 
endless loop
                 Key: CXF-6531
                 URL: https://issues.apache.org/jira/browse/CXF-6531
             Project: CXF
          Issue Type: Bug
          Components: JMS, Transports
    Affects Versions: 3.0.5
            Reporter: Waldemar Szostak
            Priority: Critical


In one-way communication (fire & forget), if:
* there is an exception thrown by the user code, or 
* the message is not a valid SOAP message, or 
* the message's SOAP body is not a valid XML, 

the exception is not handled, but instead propagated down to the message 
listener causing the session to be rolled back (and thus the message to be 
un-acknowledged), which sort of puts the message back in the topic and makes it 
eligible for a re-delivery.

Of course, the message itself is not modified, so we have a circle..

Even though this is one-way communication, I would either expect a fault 
message to be generated, or the exception to be logged as error and have the 
message acknowledged ('removed from the topic'). The latter scenario at least 
for validation or unmarshalling exception - the exception will always be 
generated then (unlike the user code exceptions which may be due to temporary 
problems).

In my project, I need transactions in my fire&forget communication to ensure 
the message will be processed, despite any temporary problems, eg, with the 
database (=exceptions from my code). However, in situations when a client sends 
an invalid message to my service, I definitely do not want this message to 
block my service by being constantly re-delivered.

Especially, please note that currently I have no control via my code or CXF  
configuration to have such invalid XML messages simply disregarded. Either I 
need to turn off transactions (which I do not want to do because of my business 
exceptions which should cause the message to be re-delivered), or override the 
is-one-way property (see also JMSDestination.processExceptions):
{code}message.getExchange().setOneWay(false);{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to