activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Kranes (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ARTEMIS-1871) Artemis STOMP heartbeater continues after client is gone
Date Thu, 17 May 2018 19:21:00 GMT

     [ https://issues.apache.org/jira/browse/ARTEMIS-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jon Kranes updated ARTEMIS-1871:
--------------------------------
    Description: 
Under specific conditions the STOMP server continues to execute the heartbeat runnable task
even after the client connection has closed.  In the extreme case this can result in eventual
server failure since a new StompConnection and associated scheduled task are kept in memory
indefinitely and a new one is created each time a client connects.  Therefore if a client
repeatedly connects and triggers the error in a loop, eventually the server will run out of
resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate subscription ID. 
The server correctly sends an ERROR frame to the client and closes the connection, but does
not properly clean up the heartbeater which continues to run indefinitely according to the
defined interval, even though there is no client to respond.

See the attached integration test for details.  (This is a modified version of an existing
test for a similar issue that was fixed for version 1.5.3).  The test code is src/test/java/org/apache/artemis/tests/integration/stomp/v11/StompV11Test.java.

  was:
Under specific conditions the STOMP server continues to execute the heartbeat runnable task
even after the client connection has closed.  In the extreme case this can result in eventual
server failure since a new StompConnection and associated scheduled task are kept in memory
indefinitely and a new one is created each time a client connects.  Therefore if a client
repeatedly connects and triggers the error in a loop, eventually the server will run out of
resources.

The condition occurs when using STOMP 1.2, if a client sends a duplicate subscription ID. 
The server correctly sends an ERROR frame to the client and closes the connection, but does
not properly clean up the heartbeater which continues to run indefinitely according to the
defined interval, even though there is no client to respond.

See the attached integration test for details.  (This is a modified version of an existing
test for a similar issue that was fixed for version 1.5.3).


> Artemis STOMP heartbeater continues after client is gone
> --------------------------------------------------------
>
>                 Key: ARTEMIS-1871
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1871
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: STOMP
>    Affects Versions: 1.5.3
>            Reporter: Jon Kranes
>            Assignee: Justin Bertram
>            Priority: Major
>         Attachments: integration-tests.zip
>
>
> Under specific conditions the STOMP server continues to execute the heartbeat runnable task
even after the client connection has closed.  In the extreme case this can result in eventual
server failure since a new StompConnection and associated scheduled task are kept in memory
indefinitely and a new one is created each time a client connects.  Therefore if a client
repeatedly connects and triggers the error in a loop, eventually the server will run out of
resources.
> The condition occurs when using STOMP 1.2, if a client sends a duplicate subscription
ID.  The server correctly sends an ERROR frame to the client and closes the connection, but
does not properly clean up the heartbeater which continues to run indefinitely according
to the defined interval, even though there is no client to respond.
> See the attached integration test for details.  (This is a modified version of an existing
test for a similar issue that was fixed for version 1.5.3).  The test code is src/test/java/org/apache/artemis/tests/integration/stomp/v11/StompV11Test.java.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message