Announcement Announcement Module
Collapse
No announcement yet.
CachingConnectionFactory doesn't reset connections on error. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • CachingConnectionFactory doesn't reset connections on error.

    Hi,

    I'm using the CachingConnectionFactory in standalone mode (outside of spring context) to cache connections and session for my jms application. All works well and the connections and sessions are cached. However, I am having trouble resetting the connection when an exception occurs. I see that the SingleConnectionFactory (super class of CachingConnectionFactory) implements the ExceptionListener interface and therefore implements the onException method. However, when I debug the application and throw a JMS exception, the the onException method is never called and the connection is never reset. Here is how I initialize the connection factory, setting an instance of itself as the exception listener.

    Code:
    factory = new CachingConnectionFactory();
    factory.setExceptionListener(factory);
    factory.setTargetConnectionFactory(qcFactory);
    Is this the right way to initialize the factory so its onException method is called?

    Thanks in advance.

  • #2
    The SingleConnectionFactory registers itself as an ExceptionListener, so no need to use that. I also wonder why are you constructing it in java code and not simply in your applicationcontext, make sure you are using this ConnectionFactory instead of your qcFactory.

    Comment


    • #3
      My app is not configured using Spring so putting it in the appContext is not an option. Also I use vanilla JMS, not the JmsTemplate. I just wanted to hook in the CachingConnectionFactory for connection and session caching. This all works well and logging shows that it creates a shared connection and retrieves a cached session everytime. However the exception listener doesn't fire to reset the connection on error. Any idea why this would happen?

      Comment


      • #4
        How are you throwing the JMSException. Do you just put a throw new JMSException in your test code or do you throw it in for instance the createMessage or createSession method of the connection. The latter should invoke the onException, the first shouldn't because it isn't intercepted by the JMS framework.

        Comment


        • #5
          Ok so the place where the exception is thrown could be key. It happens when sending a message to the queue. So the flow is as follows...


          Initially the shared connection and session are created.
          Code:
          [pool-1-thread-1] INFO - Established shared JMS Connection: com.ibm.mq.jms.MQQueueConnection@10d3f0d
          [pool-1-thread-1] DEBUG - Created cached Session for mode 0: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] DEBUG - Created cached MessageProducer for destination [queue:///MyQueue]: com.ibm.mq.jms.MQQueueSender@d61aef
          [pool-1-thread-1] DEBUG - Returned cached Session: com.ibm.mq.jms.MQQueueSession@f449b8

          Subsequent jms calls use the cached session

          Code:
          [pool-1-thread-1] DEBUG - Found cached Session for mode 0: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] DEBUG - Found cached MessageProducer for destination [queue:///MyQueue]: com.ibm.mq.jms.MQQueueSender@d61aef
          [pool-1-thread-1] DEBUG - Returned cached Session: com.ibm.mq.jms.MQQueueSession@f449b8

          Now I take the queue down and try to send another message

          Code:
          [pool-1-thread-1] DEBUG - Found cached Session for mode 0: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] DEBUG - Found cached MessageProducer for destination [queue:///MyQueue]: com.ibm.mq.jms.MQQueueSender@d61aef
          [pool-1-thread-1] DEBUG - Returned cached Session: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] ERROR -  unable to send message with logging event
          javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue
          	at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:622)
          	at com.ibm.mq.jms.MQMessageProducer.sendInternal(MQMessageProducer.java:1827)
          	at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1139)
          	at org.springframework.jms.connection.CachedMessageProducer.send(CachedMessageProducer.java:121)
          	at com.web.jms.JmsSender.send(JmsSender.java:175)
          	......
          	......
          	......

          I was hoping this would reset the connection so that when I restart the queue the application would re-establish a new connection. Unfortunately, it does not and I get the same thing on the next call because the underlying connection is somehow corrupt.

          Code:
          [pool-1-thread-1] DEBUG - Found cached Session for mode 0: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] DEBUG - Found cached MessageProducer for destination [queue:///MyQueue]: com.ibm.mq.jms.MQQueueSender@d61aef
          [pool-1-thread-1] DEBUG - Returned cached Session: com.ibm.mq.jms.MQQueueSession@f449b8
          [pool-1-thread-1] ERROR -  unable to send message with logging event
          javax.jms.JMSException: MQJMS2007: failed to send message to MQ queue
          	at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:622)
          	at com.ibm.mq.jms.MQMessageProducer.sendInternal(MQMessageProducer.java:1827)
          	at com.ibm.mq.jms.MQMessageProducer.send(MQMessageProducer.java:1139)
          	at org.springframework.jms.connection.CachedMessageProducer.send(CachedMessageProducer.java:121)
          	at com.web.jms.JmsSender.send(JmsSender.java:175)
          Does the exception listener only trigger if there is an exception creating the connection? From looking at the code, this will only happen the first time. Is there some way to reset the connection if a problem occurs for subsequent calls?

          Thanks.

          Comment


          • #6
            setReconnectOnException

            I am also facing the same problem. The documentation clearly says

            void setReconnectOnException(boolean reconnectOnException)
            Specify whether the single Connection should be reset (to be subsequently renewed) when a JMSException is reported by the underlying Connection.


            the connection will be subsequently renewed. However can this be done in a proactive manner. Something like a cleaning the connection over a period of time. Something like that.

            I have seen this with JDBC connections. Is this possible with CachingConnectionFactory?

            Regards,
            Franklin

            Comment


            • #7
              I don't think there's a way to configure the CachingConnectionFactory to proactively close the connection after a period of time. One custom solution is to implement a timer in your code which invokes the public resetConnection() method on SingleConnectionFactory after a certain period of inactivity. This will result in a new connection being establish for the next JMS send.

              I would also like this reset/time-out functionality but I don't think its available.

              Comment


              • #8
                This feature would have been good

                Ouch...I really wish it was there. The custom implementation looks fine but the only worry is , what if the resetConnection is called(by some timer/scheduler) when actually the connection is being used. However the chances are still less though. Again doing this, wouldnt the class be more like SingleConnectionFactory(in terms of behaviour)

                Anyways, since the class is a "Cahing" class , it would be really good if such a facility would be there.

                Right now, the thing that can give me the expected behaviour is SingleConnectionFactory and I really wouldnt recommend using it on prodcution.

                Hope to see this facility soon.

                Regards,
                Franklin

                Comment

                Working...
                X