You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Marat Bedretdinov (JIRA)" <ji...@apache.org> on 2008/06/25 00:11:00 UTC
[jira] Created: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
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.4.0
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.
[jira] Updated: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Bedretdinov updated CAMEL-634:
------------------------------------
Attachment: (was: tx.fix.2008-06-24-16-54.patch)
> 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.4.0
>
>
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43741#action_43741 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
Marat we appreciate all your great patches for the more hardcore JMS related stuff.
I am sure this patch will be accepted and submitted to the trunk.
The 1.4 should just be voted released before we will apply this patch to the trunk that is for the 1.5 release.
The vote for 1.4 release is in progress as I write this.
http://www.nabble.com/-VOTE--Release-apache-camel-1.4-td18146965s22882.html
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Hadrian Zbarcea (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43827#action_43827 ]
Hadrian Zbarcea commented on CAMEL-634:
---------------------------------------
Can this issue be closed?
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43708#action_43708 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
Marat thanks a lot for the patch, we appreciate all the hard work you do to report and fix the problems. Great work.
As the 1.4 release is just about to get cut I would like to schedule this patch for 1.5. I am hoping that you don't mind this.
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43781#action_43781 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
The unit tests now all *passes* sorry my bad
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43777#action_43777 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
According to the spring transaction programmatic stuff you can set the rollback only status.
I am wondering if we should do this also when we do the rollback by throwing the wrapped exception?
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43775#action_43775 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
Marat.
Could you provide a unit test for the new class ExchangeProperty also?
> 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.
[jira] Work started: (CAMEL-634) DeadLetterChannel default
redelivery policy eclipsed expected transactional behaviour in a transacted
route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on CAMEL-634 started by Claus Ibsen.
> 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
> Assignee: Claus Ibsen
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43814#action_43814 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
D:\project\camel>svn commit --message "CAMEL-634: Applied patch with thanks to Marat. Added unit test for transactional DataSource."
Sending camel-core\src\main\java\org\apache\camel\Exchange.java
Adding camel-core\src\main\java\org\apache\camel\ExchangeProperty.java
Sending camel-core\src\main\java\org\apache\camel\impl\DefaultExchange.java
Sending camel-core\src\main\java\org\apache\camel\processor\DeadLetterChannel.java
Adding camel-core\src\test\java\org\apache\camel\ExchangePropertyTest.java
Sending components\camel-jms\src\main\java\org\apache\camel\component\jms\EndpointMessageListener.java
Sending components\camel-jms\src\test\java\org\apache\camel\component\jms\tx\ConditionalExceptionProcessor.java
Sending components\camel-jms\src\test\java\org\apache\camel\component\jms\tx\QueueToQueueRequestReplyTransactionTest.java
Sending components\camel-spring\pom.xml
Sending components\camel-spring\src\main\java\org\apache\camel\spring\spi\TransactionInterceptor.java
Adding components\camel-spring\src\test\java\org\apache\camel\spring\interceptor\BookService.java
Adding components\camel-spring\src\test\java\org\apache\camel\spring\interceptor\TransactionalClientDataSourceTest.java
Adding components\camel-spring\src\test\resources\org\apache\camel\spring\interceptor\transactionalClientDataSource.xml
Transmitting file data .............
Committed revision 673008.
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.
[jira] Updated: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-634:
------------------------------
Fix Version/s: 1.5.0
(was: 1.4.0)
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43778#action_43778 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
I do think I got a failing exception on my local system with the patch.
{code}
-------------------------------------------------------------------------------
Test set: org.apache.camel.component.jms.tx.QueueToQueueRequestReplyTransactionTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 23.047 sec <<< FAILURE!
testRollbackUsingXmlQueueToQueueRequestReplyUsingDynamicMessageSelector(org.apache.camel.component.jms.tx.QueueToQueueRequestReplyTransactionTest) Time elapsed: 22.875 sec <<< FAILURE!
junit.framework.AssertionFailedError: Received unexpeced reply
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at org.apache.camel.component.jms.tx.QueueToQueueRequestReplyTransactionTest.testRollbackUsingXmlQueueToQueueRequestReplyUsingDynamicMessageSelector(QueueToQueueRequestReplyTransactionTest.java:70)
{code}
> 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.
[jira] Updated: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-634:
------------------------------
Fix Version/s: 1.4.0
(was: 1.5.0)
We should get this in 1.4 before its release. To important to not include as the transaction client EIP pattern doesn't work otherwise.
Marats patch is surely great. Just need it to be more polished that he is working on ;)
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43808#action_43808 ]
Marat Bedretdinov commented on CAMEL-634:
-----------------------------------------
Claus:
Updated patch is attached. Note, I've added type safety check on DefaultExchange for well known set of Exchange Properties
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43805#action_43805 ]
Marat Bedretdinov commented on CAMEL-634:
-----------------------------------------
Claus:
> Could you provide a unit test for the new class ExchangeProperty also?
Working on it.
> I am wondering if we should introduce an method on Exchange interface that returns whether this exchange is in transacted mode or not?
Sure. Will add that
> According to the spring transaction programmatic stuff you can set the rollback only status. And I am wondering if we should do this also when we do the rollback by throwing the wrapped exception?
I can add that, however it has no effect on JMS tx being rolled back as there is a bug in the way tx management is implemented in Spring's JMS DefaultListenerContainer
> We are adding a TRANSACTED property on the Exchange that is never removed.
That's not quite true I believe. As far as I can tell an Exchange lifespan is a single call flow. So if this call flow is transacted then this property is installed on it. Once this Exchange instance is freed so are its properties.
> As this class is in org.apache.camel package I do think it should have javadoc stating its purpose.
Working on that as well.
> 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
> Assignee: Claus Ibsen
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43776#action_43776 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
And I am wondering if we should introduce an method on Exchange interface that returns whether this exchange is in transacted mode or not?
> 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.
[jira] Resolved: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-634.
-------------------------------
Resolution: Fixed
Yes it can.
Marat should just document why he uses the code he does to retrieve if the exchange is transacted from the spring TM
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43813#action_43813 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
Marat, do you mind documenting why you are looking as you do, for the active TX, in the code below?
You are first looking into the TSM if not found then on status, and then on the casting to DTS etc.
Is all this code really needed? You had to do it like this? I am asking because when someone else look at this code in 1-2 years he would be a little puzzled?
So I do think we should add some code comments on the strategy below and why it needed to do it like this.
You can just comment here and I will add it to the code.
{code}
activeTx = TransactionSynchronizationManager.isActualTransactionActive();
+ if (!activeTx) {
+ activeTx = status.isNewTransaction() && !status.isCompleted();
+ if (!activeTx) {
+ if (DefaultTransactionStatus.class.isAssignableFrom(status.getClass())) {
+ DefaultTransactionStatus defStatus = DefaultTransactionStatus.class.cast(status);
+ activeTx = defStatus.hasTransaction() && !status.isCompleted();
+ }
+ }
+ }
{code}
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.
[jira] Assigned: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned CAMEL-634:
---------------------------------
Assignee: Claus Ibsen
> 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
> Assignee: Claus Ibsen
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43782#action_43782 ]
Claus Ibsen commented on CAMEL-634:
-----------------------------------
Marat your ExchangeProperty is quite nice. As this class is in org.apache.camel package I do think it should have javadoc stating its purpose.
Other components and end-users could start using it so it should be clearly documented and ... we should have an unit test for it also.
> 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.
[jira] Commented: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43733#action_43733 ]
Marat Bedretdinov commented on CAMEL-634:
-----------------------------------------
Claus,
I don't mind that as long as the patch can be applied to trunk and the sooner the better :)
> 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.
[jira] Updated: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Bedretdinov updated CAMEL-634:
------------------------------------
Attachment: tx.fix.2008-06-24-16-54.patch
> 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.4.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.
[jira] Updated: (CAMEL-634) DeadLetterChannel default redelivery
policy eclipsed expected transactional behaviour in a transacted route
Posted by "Marat Bedretdinov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marat Bedretdinov updated CAMEL-634:
------------------------------------
Attachment: tx.fix.2008-06-30-19-16.patch
> 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
> Assignee: Claus Ibsen
> Fix For: 1.4.0
>
> Attachments: tx.fix.2008-06-24-16-54.patch, tx.fix.2008-06-30-19-16.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.