Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-dev@activemq.apache.org
Message-ID: <884099164.1214758801691.JavaMail.jira@brutus>
Date: Sun, 29 Jun 2008 10:00:01 -0700 (PDT)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
 policy eclipsed expected transactional behaviour in a transacted route
In-Reply-To: <1226149765.1214345460298.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43780#action_43780 ] 

Claus Ibsen commented on CAMEL-634:
-----------------------------------

I am wondering if we should also cleanup? We are adding a TRANSACTED property on the Exchange that is never removed.

> DeadLetterChannel default redelivery policy eclipsed expected transactional behaviour in a transacted route
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-634
>                 URL: https://issues.apache.org/activemq/browse/CAMEL-634
>             Project: Apache Camel
>          Issue Type: Bug
>          Components: camel-core, camel-jms
>    Affects Versions: 1.4.0
>            Reporter: Marat Bedretdinov
>             Fix For: 1.5.0
>
>         Attachments: tx.fix.2008-06-24-16-54.patch
>
>
> Camel routes get a DLC processor with a redelivery policy, which defaults to redeliverying a message to a destination processor up to 6 times.  In case of a transacted route it is preferable that DLC's delivery policy be reset to a single attempt, so that a fan-out transacted route would not hold tx locks on destinations for too long. 
> The DLC's default redelivery policy has also made transactional tests not really testing tx behavior of Camel Components backed runtimes (jms brokers, etc), rather DLC would catch the exception and try to redeliver the message to destination processor and not letting the components to rollback native transactions initiated by components backed runtimes (jms, db)
> The attached patch installs a property into Camel Exchange that indicates weather a route is transacted. This is done in org.apache.camel.spring.spi.TransactionInterceptor.java
> DLC then checks if the flow is transacted and sets its redelivery policy to 1
> With this change JMS transactions are actually rolled back and messages are put back into the queue and then consumed again, verifying that brokers support transactions and can redeliver messages into Camel routes that were previously rolled back.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.