[
https://issues.apache.org/jira/browse/ARTEMIS-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1873:
------------------------------------
Description:
StompConnection.java (it's in artemis-stomp-protocol) utilizes a
{{VersionedStompFrameHandler}} frame handler which in the case of STOMP 1.1 and
1.2 contains a heartbeat scheduler.
This scheduler is stopped when {{StompConnection.fail()}} is called but not for
{{StompConnection.destroy()}}. So in some cases you may get dangling heartbeat
threads from destroyed connections. These threads simply try to send heartbeats
to dead clients resulting in following warnings:
{noformat}
2018-05-17 17:01:06,591 WARN [org.apache.activemq.artemis.core.protocol.stomp]
(Thread-22
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@6b9ec8e5))
AMQ222068: connection closed
org.apache.activemq.artemis.core.protocol.stomp.StompConnection@5d5327f9{noformat}
In my opinion it's just a simple oversight. From what I see ARTEMIS-934 did
only fix the issue for {{StompConnection.fail()}}. But RemoteConnections (which
is StompConnection) can also be destroy()'ed.
Here's example diff that may fix it:
{noformat}
diff --git
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
index fbd010775..4c11108c3 100644
---
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
+++
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
@@ -335,9 +335,10 @@ public final class StompConnection implements
RemotingConnection {
if (destroyed) {
return;
}
+
+ destroyed = true;
}
- destroyed = true;
internalClose();
@@ -351,6 +352,10 @@ public final class StompConnection implements
RemotingConnection {
}
private void internalClose() {
+ if (frameHandler != null) {
+ frameHandler.disconnect();
+ }
+
transportConnection.close();
manager.cleanup(this);
@@ -372,9 +377,6 @@ public final class StompConnection implements
RemotingConnection {
ActiveMQServerLogger.LOGGER.connectionFailureDetected(me.getMessage(),
me.getType());
- if (frameHandler != null) {
- frameHandler.disconnect();
- }
// Then call the listeners
callFailureListeners(me);
{noformat}
was:
StompConnection.java (it's in artemis-stomp-protocol) utilizes a "
VersionedStompFrameHandler" frame handler which (in case of STOMP 1.1 and 1.2)
contains a heartbeat scheduler.
This scheduler is stopped when StompConnection.fail() is called but not for
.destroy().
So in some cases you may get dangling heartbeat threads from destroyed
connections. These threads simply try to send heartbeats to dead clients
resulting in following warnings:
{noformat}
2018-05-17 17:01:06,591 WARN [org.apache.activemq.artemis.core.protocol.stomp]
(Thread-22
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@6b9ec8e5))
AMQ222068: connection closed
org.apache.activemq.artemis.core.protocol.stomp.StompConnection@5d5327f9{noformat}
In my opinion it's just a simple oversight. From what I see ARTEMIS-934 did
only fix the issue for .fail() method. But RemoteConnections (which is
StompConnection) can also be destroy()'ed.
Here's example diff that may fix it:
{code:java}
diff --git
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
index fbd010775..4c11108c3 100644
---
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
+++
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
@@ -335,9 +335,10 @@ public final class StompConnection implements
RemotingConnection {
if (destroyed) {
return;
}
+
+ destroyed = true;
}
- destroyed = true;
internalClose();
@@ -351,6 +352,10 @@ public final class StompConnection implements
RemotingConnection {
}
private void internalClose() {
+ if (frameHandler != null) {
+ frameHandler.disconnect();
+ }
+
transportConnection.close();
manager.cleanup(this);
@@ -372,9 +377,6 @@ public final class StompConnection implements
RemotingConnection {
ActiveMQServerLogger.LOGGER.connectionFailureDetected(me.getMessage(),
me.getType());
- if (frameHandler != null) {
- frameHandler.disconnect();
- }
// Then call the listeners
callFailureListeners(me);
{code}
> AMQ222068: STOMP heartbeat handler is not stopped after
> StompConnection.destroy()
> ---------------------------------------------------------------------------------
>
> Key: ARTEMIS-1873
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1873
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
> Affects Versions: 2.7.0
> Reporter: Paweł Puterla
> Assignee: Justin Bertram
> Priority: Major
>
> StompConnection.java (it's in artemis-stomp-protocol) utilizes a
> {{VersionedStompFrameHandler}} frame handler which in the case of STOMP 1.1
> and 1.2 contains a heartbeat scheduler.
> This scheduler is stopped when {{StompConnection.fail()}} is called but not
> for {{StompConnection.destroy()}}. So in some cases you may get dangling
> heartbeat threads from destroyed connections. These threads simply try to
> send heartbeats to dead clients resulting in following warnings:
>
> {noformat}
> 2018-05-17 17:01:06,591 WARN
> [org.apache.activemq.artemis.core.protocol.stomp] (Thread-22
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@6b9ec8e5))
> AMQ222068: connection closed
> org.apache.activemq.artemis.core.protocol.stomp.StompConnection@5d5327f9{noformat}
>
> In my opinion it's just a simple oversight. From what I see ARTEMIS-934 did
> only fix the issue for {{StompConnection.fail()}}. But RemoteConnections
> (which is StompConnection) can also be destroy()'ed.
> Here's example diff that may fix it:
> {noformat}
> diff --git
> a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
>
> b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
> index fbd010775..4c11108c3 100644
> ---
> a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
> +++
> b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
> @@ -335,9 +335,10 @@ public final class StompConnection implements
> RemotingConnection {
> if (destroyed) {
> return;
> }
> +
> + destroyed = true;
> }
> - destroyed = true;
> internalClose();
> @@ -351,6 +352,10 @@ public final class StompConnection implements
> RemotingConnection {
> }
> private void internalClose() {
> + if (frameHandler != null) {
> + frameHandler.disconnect();
> + }
> +
> transportConnection.close();
> manager.cleanup(this);
> @@ -372,9 +377,6 @@ public final class StompConnection implements
> RemotingConnection {
> ActiveMQServerLogger.LOGGER.connectionFailureDetected(me.getMessage(),
> me.getType());
> - if (frameHandler != null) {
> - frameHandler.disconnect();
> - }
> // Then call the listeners
> callFailureListeners(me);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
