[
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
