cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6531) Exception-triggerring messages are re-delivered in endless loop
Date Wed, 19 Apr 2017 11:25:42 GMT

    [ https://issues.apache.org/jira/browse/CXF-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974468#comment-15974468
] 

Christian Schneider commented on CXF-6531:
------------------------------------------

You need to configure your broker to deliver such messages to a dead letter queue (DLQ) after
a certain number of tries. You can do this centrally on the broker or in the ConnectionFactory.

This is how to do this in ActiveMQ:
http://activemq.apache.org/redelivery-policy.html



> 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.15#6346)

Mime
View raw message