[mule-user] JMS Connector stopping intermittently with 1.4.3?

[Nick Bower]

I have a tomcat/spring application using Mule to subscribe to an ActiveMQ topic.  Here's the connector:

  <bean id="jmsConnector" class="org.mule.providers.jms.JmsConnector">
      <property name="connectionFactoryJndiName">
          <value>ConnectionFactory</value>
      </property>
    <property name="jndiProviderProperties">
        <map>
            <entry key="java.naming.factory.initial">
                <value>org.apache.activemq.jndi.ActiveMQInitialContextFactory</value>
            </entry>
            <entry key="java.naming.provider.url">
                <value>tcp://tsunamiclone:61616</value>
            </entry>
        </map>
    </property>
  </bean>


Unfortunately this will run for a random amount of time (eg a day) then the JMS connector will stop unpredictably, then does not recover and messages are no longer received.  There seems to be much of correspondence on similar issues leaving me confused as to whether JMS has been fixed or not.  Should I be:

1) adding a connection-strategy to the bean above (if so, how syntactically?), or
2) not using Mule and reverting to a standard Spring/JMS configuration until the bugs with reconnection strategies are fixed (no fix targets in Jira seem to be set btw)

Thanks, Nick

INFO  2008-02-07 16:11:34,214 [messageServiceDescriptor.166] com.metoceanengineers.datafeeds.monitor.NcmlMessageService: Received message for Metocean Office
INFO  2008-02-07 16:11:34,250 [messageServiceDescriptor.166] com.metoceanengineers.datafeeds.monitor.NcmlMessageService: Received message for Metocean Office
INFO  2008-02-07 16:11:34,316 [messageServiceDescriptor.166] com.metoceanengineers.datafeeds.monitor.NcmlMessageService: Received message for Metocean Office
INFO  2008-02-07 16:12:04,318 [AcitveMQ Connection Worker: tcp://tsunamiclone/172.17.230.198:61616] org.mule.providers.jms.JmsConnector: Stopping: JmsConnector{this=43059849, started=true, initialised=true, name='jmsConnector', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[jms], serviceOverrides=null}
ERROR 2008-02-07 16:12:04,321 [AcitveMQ Connection Worker: tcp://tsunamiclone/172.17.230.198:61616] org.mule.providers.jms.JmsConnector: Failed to close jms message consumer
javax.jms.JMSException: The transport is not running.
        at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:58)
        at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1185)
        at org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1663)
        at org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:542)
        at org.mule.providers.jms.JmsConnector.close(JmsConnector.java:947)
        at org.mule.providers.jms.JmsConnector.closeQuietly(JmsConnector.java:961)
        at org.mule.providers.jms.SingleJmsMessageReceiver.closeConsumer(SingleJmsMessageReceiver.java:165)
        at org.mule.providers.jms.SingleJmsMessageReceiver.doDisconnect(SingleJmsMessageReceiver.java:74)
        at org.mule.providers.AbstractMessageReceiver.disconnect(AbstractMessageReceiver.java:437)
        at org.mule.providers.AbstractMessageReceiver.stop(AbstractMessageReceiver.java:469)
        at org.mule.providers.AbstractConnector.stopConnector(AbstractConnector.java:428)
        at org.mule.providers.jms.JmsConnector$1.onException(JmsConnector.java:284)
        at org.apache.activemq.ActiveMQConnection$4.run(ActiveMQConnection.java:1524)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: The transport is not running.
        at org.apache.activemq.transport.TransportSupport.checkStarted(TransportSupport.java:103)
        at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:117)
        at org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor.java:141)
        at org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.java:80)
        at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNegotiator.java:93)
        at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:47)
        at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(ResponseCorrelator.java:69)
        at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:74)
        at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1175)
        ... 14 more

[Andrew Perepelytsya]

If it is something that happens under load, I think something like this has been fixed with 1.4.4 and some extra assistance from MuleSource's commercial support. Please check with them if there's a contract available to you.

HTH,
Andrew

[Nick Bower]

Hi not according to fix targets in Jira Andrew:

http://mule.mulesource.org/jira/browse/MULE-1720
http://mule.mulesource.org/jira/browse/MULE-2303
http://mule.mulesource.org/jira/browse/MULE-2616

Hey funny how you suspected the load issue off the bat - I hadn't
considered that a connector that consumes and so moderates it's own load
(ie not client-server) could be so irretrievably affected by load.
Presumably you know something about Mule I don't! Looking at logs
however, about 20 messages/sec were being consumed (ie not high I would
have thought).

Could you confirm by the way if configuring a spring bean with a
(re)connection strategy is not possible then?

I take your point about support - I would have considered that for cases
in which you're trying to do something outside the product spec though,
this being bread and butter JMS consumption that many others seem to
have reported. Of course my experience here is limited.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email