0 Replies Latest reply on Jun 6, 2012 4:29 AM by Miguel Moquillon

    Any idea why we have an unexpected connection failure with a single maintained connection?

    Miguel Moquillon Newbie



      We use HornetQ with JBoss 6.1 for the inter-components notifications in our application.

      For doing, we defined an application specific API whose the current implementation wraps the JMS API and JNDI to lookup both a connection factory, topics and queues. The implementation maintains a connection and a session that is created at application initialization and that are closed at application finalization. They are then used to create durable subscribers, to create publisher (for sending messages to some topics), and so on.


      Recently, we have discovered with some of our test servers the following connection failure with HornetQ:

      [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: 
      Did not receive data from invm:0. 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=3]

      This error is hardly reproductible and occurs randomly and unexpectedly, as well in the night when there is no charge than in a plain day with users.


      The HornetQ configuration was updated by adding the confirmation-window-size parameter (valued at 10000000)  for each defined connection factory in the hornetq-jms.xml configuration file. Others parameters (connection-ttl and client-failure-check-period) are kept at their default value (respectivly 1 minute and 30 seconds according to the documentation (http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#dead.connections)).


      I expected the HornetQ client (behind the JMS API) regularly pings the server so that the latest doesn't close the connection. But it seems that it does not work like that, isn't it?


      Have you any idea about that?