[
https://issues.apache.org/jira/browse/CXF-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider resolved CXF-6531.
--------------------------------------
Resolution: Not A Problem
Can be solved by using redelivery limits
> 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
> Assignee: Christian Schneider
> 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.15#6346)
