ActiveMQ
  1. ActiveMQ
  2. AMQ-3603

STOMP 1.1 introduced the heartBeat header implemented by the inactivity monitor, would be nice to have this option for stomp 1.0

    Details

      Description

      Stomp 1.0 does not provide for an inactivity monitor. A client connect that stays idle will remain active on the broker indefinitely. With 1.1, the inactivity monitor has come into play in response to the heartBeat header. For 1.0 clients we need a way to indicate that there is a default heartBeat header, so a broker readTimeout and no expectation of a writeTimeout.
      Providing a transport option for stomp like stomp://0.0.0.0:0?transport.defaultHeartBeat=5000,0 would be nice. In the absence of a heartbeat header, as in the stomp 1.0 case, this default value would cause an InactivityMonitor with readCheck of 500 to be installed on each new broker stomp transport connection.
      Any client that remains inactive for more than 5 seconds will have their broker connection closed.

        Activity

        Hide
        Timothy Bish added a comment -

        @gtully can we close this one now? it looks complete given the SVN commits.

        Show
        Timothy Bish added a comment - @gtully can we close this one now? it looks complete given the SVN commits.
        Hide
        Erik added a comment -

        Stomp 1.0 Heartbeat works for stomp, but not stomp+ssl.

        Works:

        <transportConnector name="stomp" uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=5000,0"/>

        Does not work:

        <transportConnector name="stomp+ssl" uri="stomp+ssl://0.0.0.0:61613?transport.defaultHeartBeat=5000,0"/>

        Show
        Erik added a comment - Stomp 1.0 Heartbeat works for stomp, but not stomp+ssl. Works: <transportConnector name="stomp" uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=5000,0"/> Does not work: <transportConnector name="stomp+ssl" uri="stomp+ssl://0.0.0.0:61613?transport.defaultHeartBeat=5000,0"/>
        Hide
        Karen Morrissey added a comment - - edited

        This feature does not appear to work. I tried the following configuration in my activemq.xml:

        <transportConnector name="stomp" uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=900000,0"/>
        

        This should time out connections that are inactive for over 15 minutes (900000 milliseconds). I did remember to restart the broker.

        I launched a Perl script against my AMQ 5.8.0 broker that connected and subscribed to some wildcarded topics and then went into a long sleep without reading. Using the web console, I saw the number of consumers go up by one on the expected topics.

        I waited twenty minutes. The number of consumers did not go down. The number did go down by one when I killed the Perl script. This wasn't just a matter of the reported number of consumers. Using the web console, during the 20 minutes, I watched memory use steadily climb, which I assume was because messages were being held, waiting for the Perl script to read them. When I killed the Perl script, reported memory use immediately went to zero percent.

        In case it matters, the AMQ broker was running as a service on Windows 7 with JRE 1.7.0_05-b05 64-bit.

        Show
        Karen Morrissey added a comment - - edited This feature does not appear to work. I tried the following configuration in my activemq.xml: <transportConnector name= "stomp" uri= "stomp://0.0.0.0:61613?transport.defaultHeartBeat=900000,0" /> This should time out connections that are inactive for over 15 minutes (900000 milliseconds). I did remember to restart the broker. I launched a Perl script against my AMQ 5.8.0 broker that connected and subscribed to some wildcarded topics and then went into a long sleep without reading. Using the web console, I saw the number of consumers go up by one on the expected topics. I waited twenty minutes. The number of consumers did not go down. The number did go down by one when I killed the Perl script. This wasn't just a matter of the reported number of consumers. Using the web console, during the 20 minutes, I watched memory use steadily climb, which I assume was because messages were being held, waiting for the Perl script to read them. When I killed the Perl script, reported memory use immediately went to zero percent. In case it matters, the AMQ broker was running as a service on Windows 7 with JRE 1.7.0_05-b05 64-bit.
        Hide
        Karen Morrissey added a comment - - edited

        This feature does work, however timeout appears to take 3 times longer than specified. I created a new issue AMQ-4569 for this problem. I endorse closing the issue.

        Show
        Karen Morrissey added a comment - - edited This feature does work, however timeout appears to take 3 times longer than specified. I created a new issue AMQ-4569 for this problem. I endorse closing the issue.
        Hide
        Timothy Bish added a comment -

        You'll need to produce some test that shows this to be the case.

        Show
        Timothy Bish added a comment - You'll need to produce some test that shows this to be the case.

          People

          • Assignee:
            Gary Tully
            Reporter:
            Gary Tully
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development