On Thu, Dec 1, 2011 at 8:01 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Thu, Dec 1, 2011 at 10:08 AM, Jason Dillon <ja...@planet57.com> wrote: >> This does not really help, as if you set the retry on startup and it exceeds >> an exception is thrown and the route does not get added. >> >> I need to route to be added regardless if it can actually make a connection >> at the time of adding or not. The connectivity to the jms endpoint may or >> may not be available when the route is added, but either way the route needs >> to get added, so that when the connectivity is available that messages will >> flow. >> > > We should possible add an option to JmsConsumer so you can instruct it > to startup using a spawned thread, so the route can continue to be > started. And as you say the startup process may successfully connect > later. This depends if the JMS Client supports automatic failover and > re-connect attempts as the AMQ client does in this case. > > Fell free to create a JIRA ticket. >
I have created a ticket to track this https://issues.apache.org/jira/browse/CAMEL-4770 > >> --jason >> >> >> On Nov 30, 2011, at 11:02 PM, Claus Ibsen wrote: >> >>> AMQ have a startup max reconnect attempt option you can use >>> http://activemq.apache.org/failover-transport-reference.html >>> >>> >>> On Thu, Dec 1, 2011 at 12:01 AM, Jason Dillon <ja...@planet57.com> wrote: >>>> I'm running into a problem where CamelContext.addRoutes() is blocking when >>>> adding a route that uses a jms endpoint that is configured with AcitveMQ's >>>> failover transport and the remote server is down. >>>> >>>> This specific jms endpoint is configured to use SingleConnectionFactory >>>> and ConsumerType.Simple to reduce thread usage. Looks like when the >>>> consumer is started, that it attempts to open up the connection: >>>> >>>> <snip> >>>> jvm 1 | java.lang.Thread.State: TIMED_WAITING (on object monitor) >>>> jvm 1 | at java.lang.Object.wait(Native Method) >>>> jvm 1 | - waiting on <7cbecd168> (a java.lang.Object) >>>> jvm 1 | at >>>> org.apache.activemq.transport.failover.FailoverTransport.oneway(FailoverTransport.java:516) >>>> jvm 1 | - locked <7cbecd168> (a java.lang.Object) >>>> jvm 1 | at >>>> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40) >>>> jvm 1 | - locked <7cbecd1b8> (a java.lang.Object) >>>> jvm 1 | at >>>> org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:81) >>>> jvm 1 | at >>>> org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:86) >>>> jvm 1 | at >>>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1284) >>>> jvm 1 | at >>>> org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1392) >>>> jvm 1 | - locked <7cbecd340> (a java.lang.Object) >>>> jvm 1 | at >>>> org.apache.activemq.ActiveMQConnection.createSession(ActiveMQConnection.java:309) >>>> jvm 1 | at >>>> org.springframework.jms.support.JmsAccessor.createSession(JmsAccessor.java:196) >>>> jvm 1 | at >>>> org.springframework.jms.listener.SimpleMessageListenerContainer.initializeConsumers(SimpleMessageListenerContainer.java:249) >>>> jvm 1 | - locked <7cbecd3d0> (a java.lang.Object) >>>> jvm 1 | at >>>> org.springframework.jms.listener.SimpleMessageListenerContainer.doInitialize(SimpleMessageListenerContainer.java:188) >>>> jvm 1 | at >>>> org.springframework.jms.listener.AbstractJmsListeningContainer.initialize(AbstractJmsListeningContainer.java:193) >>>> jvm 1 | at >>>> org.springframework.jms.listener.AbstractJmsListeningContainer.afterPropertiesSet(AbstractJmsListeningContainer.java:157) >>>> jvm 1 | at >>>> org.apache.camel.component.jms.JmsConsumer.doStart(JmsConsumer.java:114) >>>> ... >>>> </snip> >>>> >>>> And failover does its job and loops forever trying to establish. This >>>> block camel from starting up fully. Is this a bug or am I misconfiguring >>>> something? Once server is up, it behaves itself and returns as expected. >>>> >>>> Any suggestions on how to work around this? I'd rather not make a new >>>> thread simply to add the route (or add not-autostart) and thread the call >>>> to start the route, but... I don't see any other way to cope with this ATM. >>>> >>>> --jason >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> FuseSource >>> Email: cib...@fusesource.com >>> Web: http://fusesource.com >>> Twitter: davsclaus, fusenews >>> Blog: http://davsclaus.blogspot.com/ >>> Author of Camel in Action: http://www.manning.com/ibsen/ >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
