I have some questions regarding your issue:
1) How your stomp poller connected to the single HornetQ server? Is it running at the same host machine as the HornetQ server? Is the poller a long running process?
2) Did you observed any network problem between the poller and the HornetQ server?
Yes, I should have mentioned that the STOMP poller is on the same server as the HornetQ. The poller itself runs continually under a supervisor, but the logs indicate that the connection is reset about once a minute. The poller will print out "connection.receive returning EOF as nil - resetting connection." at those times. The HornetQ will have an accompanying message in the logs that looks like:
17:12:04,977 WARN [org.hornetq.core.server] HQ222067: Connection failure has been detected: HQ119014: Did not receive data from /127.0.0.1:46527. 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]
17:12:04,979 WARN [org.hornetq.core.server] HQ222061: Client connection failed, clearing up resources for session 1d1bfe16-a914-11e2-8381-81f4cc04e5e2
17:12:04,980 WARN [org.hornetq.core.server] HQ222107: Cleared up resources for session 1d1bfe16-a914-11e2-8381-81f4cc04e5e2
I have been trying to understand why the connection is not kept open for longer, but the poller continues to receive messages after the connection is reset so I was left with the impression that it was not the root of the problem.
You have take measures to keep the connection alive. Either you enable Stomp ping (1.1, 1.2) on your poller, or you can make the stomp connection ttl (connection-ttl) very large.
Yes I will look into that more. I have more carefully configured my STOMP producers but the ActiveMessaging library doesn't seem to expose much in the way of configuring the STOMP connections it makes to consume. That said, one consumer disconnecting once a minute should not cause HornetQ to lock up permanently requiring a kill -9!
Can you help raising a Jira? I'll investigate it.