1 Reply Latest reply on Jan 27, 2014 3:03 PM by clebert.suconic

    HornetQ server blocks delivery of message until connection-ttl is reached

    aqtwrdnr
    aqtwrdnr Jan 27, 2014 9:47 AM

      Hello,

       

      When I kill my JMS consumer (without proper resource closing) and start it again directly afterwards (same host), it only starts to consume messages again after HornetQ Server has detected that the previous (not correctly closed) connection times out (dead connection detection).

       

      So, only after I see the following log-statements appear (which takes about 1 minute), my new consumer starts receiving JMS messages again:

       

      WARN  (2014-01-27 14:45:20,843) (hornetq-failure-check-thread) [org.hornetq.core.client] HQ212107: Connection failure has been detected: HQ119034: Did not receive data from /127.0.0.1:34383. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]

      WARN  (2014-01-27 14:45:20,843) (hornetq-failure-check-thread) [org.hornetq.core.server] HQ222100: Client connection failed, clearing up resources for session 5b349053-8758-11e3-b2f1-f1a7779e9c06

      WARN  (2014-01-27 14:45:20,843) (hornetq-failure-check-thread) [org.hornetq.core.server] HQ222158: Cleared up resources for session 5b349053-8758-11e3-b2f1-f1a7779e9c06

       

      I would expect that the newly created JMS consumer gets a fresh connection to the server and has no relation to the old one, but apparently the old connection blocks the new connection until it is closed.

       

      Can someone explain why HornetQ behaves like this?

       

      Thanks in advance!

       

      Barry NL

       

      Edit: just found this thread HornetQConnectionFactory.setMaxConnections which says the message might be in-flight to the previous connection (to which no consumer listens) and is only returned to the queue when the connection-ttl is reached after which the next new connection picks it up. But would this behaviour also happen when the message is posted to the queue after the new connection is created?

       

      Message was edited by: aqtwrdnr aqtwrdnr