Hi It does sounds like camel-sjms lacks the re-connect functionality that camel-jms has by the spring's default message listener container.
On Fri, Nov 8, 2013 at 2:22 PM, Harald Wellmann <hwellmann...@gmail.com> wrote: > Here's a slightly different scenario demonstrating the issue with SJMS, > this time not involving stale temp queues: > > 1) Start ActiveMQ Broker > 2) Start JBoss with Camel/SJMS consumer application > 3) Run one-shot producer application (i.e. simple program which sends one > message and then exits). > 4) Everything working fine. > 5) Stop broker -> Error messages in JBoss console from stale connections. > 6) Restart broker > 7) Re-run producer -> Nothing happens. SJMS does not reconnect. > > Replacing SJMS by JMS, the communication is reestablished automatically > after broker restart. While the broker is down, camel-jms periodically > tries to reconnect without success. > > So it seems camel-sjms is missing the reconnection feature, or am I missing > a configuration option? > > Regards, > Harald > > > 2013/11/8 Harald Wellmann <hwellmann...@gmail.com> > >> The real problem is not that the temp queue is gone, the fatal thing is >> that SJMS stops working after one attempt to send to a missing queue. >> >> I've tried to debug the situation, and it seems that SJMS creates sessions >> in advance from connections obtained from JBoss, but JBoss closes each >> connection when an exception occurs, and SJMS doesn't seem to notice that >> it's session is invalid. >> >> Regards, >> Harald >> >> >> >> 2013/11/8 Raul Kripalani <r...@evosent.com> >> >>> I don't think the situation can be avoided – if anything, it can be >>> contained via AMQ broker configuration. >>> >>> Take a look at [1]. Should be a similar situation. >>> >>> [1] >>> >>> http://stackoverflow.com/questions/6432672/activemq-how-to-handle-broker-failovers-while-using-temporary-queues >>> >>> Regards, >>> >>> *Raúl Kripalani* >>> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source >>> Integration specialist >>> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >>> http://blog.raulkr.net | twitter: @raulvk >>> >>> On Fri, Nov 8, 2013 at 11:54 AM, Harald Wellmann <hwellmann...@gmail.com >>> >wrote: >>> >>> > That might help in some cases, but I don't see how it solves the >>> problem, >>> > when the producer dies before the message TTL is over. >>> > >>> > Regards, >>> > Harald >>> > >>> > >>> > 2013/11/8 Raul Kripalani <r...@evosent.com> >>> > >>> > > If these are request-reply interactions, producers should set a Time >>> To >>> > > Live when sending a message to the queue. The broker will then expire >>> > stale >>> > > messages automatically and they won't be delivered to the consumer, >>> thus >>> > > reducing the risk of the consumer sending out unexpected replies like >>> > this >>> > > one. >>> > > >>> > > Regards, >>> > > >>> > > *Raúl Kripalani* >>> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open >>> Source >>> > > Integration specialist >>> > > http://about.me/raulkripalani | >>> http://www.linkedin.com/in/raulkripalani >>> > > http://blog.raulkr.net | twitter: @raulvk >>> > > >>> > > >>> > > On Fri, Nov 8, 2013 at 11:17 AM, Harald Wellmann < >>> hwellmann...@gmail.com >>> > > >wrote: >>> > > >>> > > > I'm using Camel 2.12.1 with SJMS on JBoss AS 7.2.0 with the ActiveMQ >>> > > 5.7.0 >>> > > > resource adapter and an external broker. >>> > > > >>> > > > My application has a route consuming request-reply messages from an >>> > > > ActiveMQ queue via SJMS. The connection factory is obtained from >>> JBoss >>> > > via >>> > > > @Resource injection. >>> > > > >>> > > > When I stop my application, other producers may continue sending >>> > messages >>> > > > to the queue. >>> > > > >>> > > > When I restart my application, the producers and their associated >>> > > temporary >>> > > > reply queues may be gone. >>> > > > >>> > > > Now the restarted application connects to the queue, processes a >>> > message >>> > > > and fails sending a reply to stale temp queue, resulting in an >>> > exception >>> > > > (see below) - as a result, the ActiveMQ connection is closed, and in >>> > the >>> > > > debugger I can see that all ActiveMQ worker threads are terminated. >>> > > > >>> > > > When producers send new messages (this time with active reply >>> queues), >>> > > > nothing happens. SJMS/ActiveMQ does not reconnect. >>> > > > >>> > > > Everything works fine when replacing camel-sjms by camel-jms. >>> > > > >>> > > > Is this a configuration issue, or a problem in SJMS? Any hints >>> > welcome... >>> > > > >>> > > > Best regards, >>> > > > Harald >>> > > > >>> > > > ---- >>> > > > >>> > > > 11:48:45,506 WARN >>> > > > [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] >>> > > > (ActiveMQ Connection Executor: tcp://localhost/127.0.0.1:61616 >>> @49905) >>> > > > IJ000305: Connection error occured: >>> > > > >>> > > >>> > >>> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@2bc948fb >>> > > > [state=NORMAL >>> > > > managed >>> > > > >>> > > >>> > >>> connection=org.apache.activemq.ra.ActiveMQManagedConnection@29d997e5connection >>> > > > handles=1 lastUse=1383907703668 trackByTx=false >>> > > > >>> > > >>> > >>> pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@c8350dapool >>> > > > internal context=SemaphoreArrayListManagedConnectionPool@1311ea1 >>> > > > [pool=ConnectionFactory] >>> > > > xaResource=LocalXAResourceImpl@3fd1dca3[connectionListener=2bc948fb >>> > > > connectionManager=6aec7210 warned=false currentXid=null >>> > > > productName=ActiveMQ productVersion=5.7.0 >>> > > > jndiName=java:jboss/exported/jms/ConnectionFactory] txSync=null]: >>> > > > javax.jms.JMSException: The destination >>> > > > temp-queue://ID:tehh2d002-51935-1383907217133-1:2:2 does not exist. >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:149) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:289) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:175) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:145) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.MutableBrokerFilter.addDestination(MutableBrokerFilter.java:151) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.region.RegionBroker.addProducer(RegionBroker.java:361) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.jmx.ManagedRegionBroker.addProducer(ManagedRegionBroker.java:281) >>> > > > at >>> > > > >>> > >>> org.apache.activemq.broker.BrokerFilter.addProducer(BrokerFilter.java:93) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.advisory.AdvisoryBroker.addProducer(AdvisoryBroker.java:163) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.CompositeDestinationBroker.addProducer(CompositeDestinationBroker.java:56) >>> > > > at >>> > > > >>> > >>> org.apache.activemq.broker.BrokerFilter.addProducer(BrokerFilter.java:93) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.MutableBrokerFilter.addProducer(MutableBrokerFilter.java:99) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.TransportConnection.processAddProducer(TransportConnection.java:511) >>> > > > at >>> > > > >>> org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:105) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:294) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:152) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:256) >>> > > > at >>> > > > >>> > > > >>> > > >>> > >>> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) >>> > > > at >>> > > > >>> > > >>> > >>> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:222) >>> > > > at >>> > > > >>> > >>> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:204) >>> > > > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] >>> > > > >>> > > >>> > >>> >> >> -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
