Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 92756 invoked from network); 22 Nov 2009 13:46:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Nov 2009 13:46:45 -0000 Received: (qmail 89011 invoked by uid 500); 22 Nov 2009 13:46:45 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 88943 invoked by uid 500); 22 Nov 2009 13:46:45 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 88933 invoked by uid 99); 22 Nov 2009 13:46:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Nov 2009 13:46:45 +0000 X-ASF-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of mingfang@mac.com designates 17.148.16.105 as permitted sender) Received: from [17.148.16.105] (HELO asmtpout030.mac.com) (17.148.16.105) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Nov 2009 13:46:41 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [192.168.1.126] ([24.90.81.183]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KTI006EYJL7XU40@asmtp030.mac.com> for users@camel.apache.org; Sun, 22 Nov 2009 05:46:21 -0800 (PST) Subject: Re: Jms remoting failover problem From: Ming Fang In-reply-to: <5380c69c0911220224y55f495bfge7aaa462bcd7fe99@mail.gmail.com> Date: Sun, 22 Nov 2009 08:46:19 -0500 Message-id: <61FE8C9C-12D1-4B13-8C38-AB4A57ECA202@mac.com> References: <4B05130A.6010506@gmail.com> <7307DB11-550F-462F-93AA-D3E55BECB1DA@mac.com> <0F8D2F32-AD69-43E8-A18F-6D8872C71E80@mac.com> <5380c69c0911202226o9056321rda1a5e3ef2ae5d16@mail.gmail.com> <98552B93-C017-4CFE-8A1F-2D846D03F678@mac.com> <5380c69c0911220224y55f495bfge7aaa462bcd7fe99@mail.gmail.com> To: users@camel.apache.org X-Mailer: Apple Mail (2.1077) Thanks. But I hope that assigning this issue to 2.3 is just a default and that it will be sooner once issue is reviewed. I really need this fixed asap; or at least find a workaround or will have to remove Camel from our system. On Nov 22, 2009, at 5:24 AM, Claus Ibsen wrote: > Hi > > Thanks for the sample project. I have created a ticket to lookup into this > https://issues.apache.org/activemq/browse/CAMEL-2211 > > > On Sun, Nov 22, 2009 at 6:39 AM, Ming Fang wrote: >> Here is the smallest problem that demonstrates the problem. >> >> Java file >> >> package test; >> >> import org.apache.activemq.broker.BrokerService; >> import org.apache.activemq.camel.component.*; >> import org.apache.camel.CamelContext; >> import org.apache.camel.builder.RouteBuilder; >> import org.apache.camel.component.bean.ProxyHelper; >> import org.apache.camel.impl.DefaultCamelContext; >> import org.apache.log4j.*; >> >> public class ActiveMQTest { >> >> public static void main(String[] args) throws Exception { >> //log4j >> Logger.getRootLogger().addAppender(new ConsoleAppender(new PatternLayout(PatternLayout.DEFAULT_CONVERSION_PATTERN))); >> System.getProperties().put("org.apache.camel.jmx.disabled", "true"); >> >> //needs at least 2 servers to see problem. >> simulatorServer("tcp://localhost:61616"); >> simulatorServer("tcp://localhost:61617"); >> simulatorServer("tcp://localhost:61618"); >> >> //client >> CamelContext camelContext = new DefaultCamelContext(); >> ActiveMQConfiguration configuration = new ActiveMQConfiguration(); >> configuration.setBrokerURL("failover://(tcp://localhost:61616,tcp://localhost:61617,tcp://localhost:61618)"); >> camelContext.addComponent("jms", new ActiveMQComponent(configuration)); >> camelContext.start(); >> >> //invoke server. likely to fail when sleepTime is over 30 seconds >> Echo service = ProxyHelper.createProxy(camelContext.getEndpoint("jms:queue:echo"), Echo.class); >> int sleepTime = 31000; >> while (true) { >> System.out.println(service.echo("test")); >> Thread.sleep(sleepTime); >> } >> } >> >> private static void simulatorServer(final String url) throws Exception { >> //each server is listening on a dedicated broker >> BrokerService broker = new BrokerService(); >> broker.setUseJmx(false); >> broker.setPersistent(false); >> broker.addConnector(url); >> broker.start(); >> >> ActiveMQConfiguration configuration = new ActiveMQConfiguration(); >> configuration.setBrokerURL(url); >> CamelContext camelContext = new DefaultCamelContext(); >> camelContext.addComponent("jms", new ActiveMQComponent(configuration)); >> >> camelContext.addRoutes(new RouteBuilder() { >> public void configure() { >> from("jms:queue:echo").bean(new Echo(){ >> public String echo(String text) { >> return "Echo " + text + " from " + url; >> } >> }); >> } >> }); >> camelContext.start(); >> } >> >> //server interface >> public static interface Echo{ >> String echo(String text); >> } >> } >> >> >> Pom file >> >> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> >> 4.0.0 >> test >> jmsproblem >> jar >> 1.0-SNAPSHOT >> jmsproblem >> >> >> >> org.apache.camel >> camel-core >> 2.0.0 >> >> >> org.apache.camel >> camel-jms >> 2.0.0 >> >> >> org.apache.activemq >> activemq-camel >> 5.3.0 >> >> >> >> >> >> On Nov 21, 2009, at 1:26 AM, Claus Ibsen wrote: >> >>> On Sat, Nov 21, 2009 at 7:18 AM, Ming Fang wrote: >>>> Does anyone know of a fix for this? >>>> This is a critical problem for us, and for many I would think since this is a very typical configuration. >>>> >>> >>> Have you asked /searched at the AMQ forum also? >>> >>> Try creating a small application that demonstrates your issue so its >>> easier for others to try to reproduce the issue. >>> And make that application as simple as possible so there are less >>> moving parts to get confused by. >>> >>> >>> >>>> On Nov 19, 2009, at 6:59 AM, Ming Fang wrote: >>>> >>>>> Yes changing idelTimeOut in org.apache.activemq.pool.ConnectionPool to a very large number would be a workaround. >>>>> However I don't see anyway of doing that in org.apache.activemq.camel.component.ActiveMQConfiguration. >>>>> >>>>> But ultimately I think the way Camel uses JMS is just wrong; >>>>> The use of a Requestor to listen for out messages will always be a problem because it's not guarantee to be listening on the same broker as the publisher. >>>>> --ming >>>>> >>>>> On Nov 19, 2009, at 4:42 AM, Willem Jiang wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> How about change the idle time of switching the broker ? >>>>>> >>>>>> If the idle time is larger than your application response time, you will not get this kind trouble anymore. >>>>>> >>>>>> Willem >>>>>> >>>>>> Ming Fang wrote: >>>>>>> Hi >>>>>>> We're using Camel 2.0 with Activemq 5.3. >>>>>>> Our app uses Camel jms remoting. >>>>>>> It's connecting to two discrete ActiveMQ brokers using the failover transport randomly. Everything works fine at first. >>>>>>> The problem happens when the app is idle for more than 30 seconds. After that any remote call will trigger Activemq client to reconnect and may end up connecting to another broker. But the problem is the Requestor does not reconnect and still connected to the original broker. The result is calls are sent to one broker but the Requestor is listening to a different broker for the response. >>>>>>> Is there a way to force the Requestor to use the same connection as the producers? >>>>>>> --Ming >>>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> Apache Camel Committer >>> >>> Author of Camel in Action: http://www.manning.com/ibsen/ >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus