You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "David Cifer (Created) (JIRA)" <ji...@apache.org> on 2012/01/27 17:24:17 UTC
[jira] [Created] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Chaos arround durable jms transacted configuration
--------------------------------------------------
Key: CAMEL-4948
URL: https://issues.apache.org/jira/browse/CAMEL-4948
Project: Camel
Issue Type: Bug
Components: camel-activemq, camel-core, camel-jms
Affects Versions: 2.8.1
Environment: JDK=1.6.29 Oracle
Reporter: David Cifer
Priority: Critical
Maybe this is two bug and maybe I miss understand something, but here is the issue.
I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
Here is the route:
from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
.log("Processign from durable: ${body}").delay(100)
.process(new ExceptionGenerator())
.log("Retrieved from durable: ${body}").to("mock:durable");
Code of the Exception generator:
public void process(Exchange arg0) throws Exception {
int i = counter.incrementAndGet();
if (i % 5 == 0) {
throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
}
}
The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
Here is the second part of the problem:
The whole test works just fine under 2.7.5
But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
To make it work above 2.7.5 You have to add manually to the connection configuration:
ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
Summary:
Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4948) Chaos arround durable jms
transacted configuration
Posted by "David Cifer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195000#comment-13195000 ]
David Cifer commented on CAMEL-4948:
------------------------------------
I changed my mind. I was able to reproduce the issue.
I've created a new route, which generates an exception, the same way as above. I made the previous queue to pass the elements at the end of the route.
I've run the test twice and again I begin to lose messages. This time activemq restart didn't sorted the problem.
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "David Cifer (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Cifer updated CAMEL-4948:
-------------------------------
Environment: JDK=1.6.24 Oracle (was: JDK=1.6.29 Oracle)
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Critical
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4948) Chaos arround durable jms
transacted configuration
Posted by "David Cifer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194973#comment-13194973 ]
David Cifer commented on CAMEL-4948:
------------------------------------
Since the entry I had additional discoveries. Basically transaction handling above 2.8.x is simply colapsed. I decided to restart the ActiveMQ instance and it sorted out the problem. However I can conform that whenever I switched back to 2.7.5 previously the ActiveMQ restart it begin to work.
But I'm affraid the transaction part of the issue maybe become un-reproducable.
Still the configuration is an issue.
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Critical
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "David Cifer (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Cifer updated CAMEL-4948:
-------------------------------
Attachment: AsyncInterMediaTest.java
Here is the example which works just fine on 2.7.5 but collapse 2.8.0
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: AsyncInterMediaTest.java, camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4948) Chaos arround durable jms
transacted configuration
Posted by "David Cifer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13201323#comment-13201323 ]
David Cifer commented on CAMEL-4948:
------------------------------------
I've checked the release notes and I wasn't able to find anything that transation policy default changed. Although I agree that the new behaviour is lot more sense.
Still I think that jms context some how mixed up worth an investigation. I've deleted the test scenario. But durring the week I try to put it together again and post it here a reproducable scenario. If unable to do it I'll close down this personaly and say sorry in the comment ;)
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: AsyncInterMediaTest.java, camelasync.zip
>
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "Claus Ibsen (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-4948.
--------------------------------
Resolution: Not A Problem
Fix Version/s: 2.10.0
Assignee: Claus Ibsen
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 2.10.0
>
> Attachments: AsyncInterMediaTest.java, camelasync.zip
>
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CAMEL-4948) Chaos arround durable
jms transacted configuration
Posted by "David Cifer (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194973#comment-13194973 ]
David Cifer edited comment on CAMEL-4948 at 1/27/12 6:19 PM:
-------------------------------------------------------------
Since the entry I had additional discoveries. Basically transaction handling above 2.8.x is simply colapsed. I decided to restart the ActiveMQ instance and it sorted out the problem. However I can conform that whenever I switched back to 2.7.5 previously the ActiveMQ restart it begin to work.
But I'm affraid the transaction part of the issue maybe become un-reproducable. Maybe it can be handled with strict configuration both on ActiveMQ and Camel side.
Still the configuration that clientID above 2.8.x has to be set on connection factory level is an issue. I lover the priority.
was (Author: edvicif):
Since the entry I had additional discoveries. Basically transaction handling above 2.8.x is simply colapsed. I decided to restart the ActiveMQ instance and it sorted out the problem. However I can conform that whenever I switched back to 2.7.5 previously the ActiveMQ restart it begin to work.
But I'm affraid the transaction part of the issue maybe become un-reproducable.
Still the configuration is an issue.
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Critical
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "David Cifer (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Cifer updated CAMEL-4948:
-------------------------------
Priority: Minor (was: Critical)
Changing priority as transaction issue may become unreproducable.
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4948) Chaos arround durable jms
transacted configuration
Posted by "David Cifer (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196227#comment-13196227 ]
David Cifer commented on CAMEL-4948:
------------------------------------
The transaction part of the issue can be removed. I found the missing messages on the ActiveMQ dead letter queue. Although it is a bit large step between 2.7.5 and 2.8.0 that from now on messages by default end on the dead letter channel.
But clientId configuration still open. The problem is worse when I begin to use spring distributed transaction. The connections messed up in Camel Context and I basically cannot connect to the same ActiveMQ multiple times. The clientId is defined in the ActiveMQConnectionFactory, but it overwrites other JMSconnections as well. So if I want to use producer to send messages it will break, that clientID already used. This is true even if I add two component. jms and activemq with different connectionfactories. These two component will use overwite each other. In javaDSL they behave differently.
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: AsyncInterMediaTest.java, camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "David Cifer (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Cifer updated CAMEL-4948:
-------------------------------
Attachment: camelasync.zip
Example project to experiment
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Critical
> Attachments: camelasync.zip
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4948) Chaos arround durable jms transacted
configuration
Posted by "Claus Ibsen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-4948:
-------------------------------
Estimated Complexity: (was: Moderate)
Remaining Estimate: (was: 168h)
Original Estimate: (was: 168h)
Its better to ask first on the @user mailing list for help, instead of creating a JIRA ticket first.
This is what we say on the getting help page at:
http://camel.apache.org/support
> Chaos arround durable jms transacted configuration
> --------------------------------------------------
>
> Key: CAMEL-4948
> URL: https://issues.apache.org/jira/browse/CAMEL-4948
> Project: Camel
> Issue Type: Bug
> Components: camel-activemq, camel-core, camel-jms
> Affects Versions: 2.8.1
> Environment: JDK=1.6.24 Oracle
> Reporter: David Cifer
> Priority: Minor
> Attachments: AsyncInterMediaTest.java, camelasync.zip
>
>
> Maybe this is two bug and maybe I miss understand something, but here is the issue.
> I've created a test. A route, which reads a JMS transacted durable, but every fifth message is thrown back by an exception.
> For example I send 10 message into the durrable, than I generate 2 exception. One for the fifth one and one for the nineth (because the fifth one going to be resend as transaction failed).
> Here is the route:
> from("jms:topic:test2?clientId=testClient&durableSubscriptionName=testSubs&transacted=true")
> .log("Processign from durable: ${body}").delay(100)
> .process(new ExceptionGenerator())
> .log("Retrieved from durable: ${body}").to("mock:durable");
> Code of the Exception generator:
> public void process(Exchange arg0) throws Exception {
> int i = counter.incrementAndGet();
> if (i % 5 == 0) {
> throw new IllegalArgumentException("Every fifth message is illegal: " + arg0.getIn().getBody());
> }
> }
> The issue, what I had is that the first message (the fifth) is rolled back just nice. But after that all message simply lost.
> This is I think the reason that since 2.8.x you have to use CACHE_NONE otherwise you mess up the transaction cache.
> Here is the second part of the problem:
> The whole test works just fine under 2.7.5
> But to make it start above that is a configuration nightmare. For example clientId and transacted options in the route definition cannot appear together.
> To make it work above 2.7.5 You have to add manually to the connection configuration:
> ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(ACTIVE_MQ_HOST);
> connectionFactory.setClientID("testClient"); // <-- This is necessary above 2.7.5 meaning 2.8.x. Under 2.8.x so example 2.7.5 will break configuration
> ctx.addComponent("activemq", ActiveMQComponent.activeMQComponent(ACTIVE_MQ_HOST));
> Summary:
> Above 2.7.5 clientId and transacted cannot appear in the same durable specification. Which makes configuration brake backward compatibilty. It has to be configured on connection factory level, which means I have to create a connectionfactory for each durable endpoint.
> Above 2.7.5 only the first transaction got rolled back. Upcomming failiures got lost.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira