[jira] [Issue Comment Edited] (CAMEL-4948) Chaos arround durable jms transacted configuration

["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