[
https://issues.apache.org/jira/browse/AMQ-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673531#comment-13673531
]
Karen Morrissey edited comment on AMQ-3603 at 6/3/13 8:57 PM:
--------------------------------------------------------------
This feature does not appear to work. I tried the following configuration in my
activemq.xml:
{code:xml}
<transportConnector name="stomp"
uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=900000,0"/>
{code}
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.
was (Author: kamorrissey):
This feature does not appear to work. I tried the following configuration
in my activemq.xml:
{code:xml}
<transportConnector name="stomp"
uri="stomp://0.0.0.0:61613?transport.defaultHeartBeat=900000,0"/>
{code}
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 on Windows 7 with JRE
1.7.0_05-b05 64-bit.
> STOMP 1.1 introduced the heartBeat header implemented by the inactivity
> monitor, would be nice to have this option for stomp 1.0
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3603
> URL: https://issues.apache.org/jira/browse/AMQ-3603
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 5.5.1
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: inactivity, monitor, stomp
> Fix For: 5.6.0
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
