[
https://issues.apache.org/jira/browse/ARTEMIS-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496661#comment-16496661
]
Jon Kranes commented on ARTEMIS-1873:
-------------------------------------
Making the patch myself is not difficult but as this is a production system,
our IT administrators are justifiably uncomfortable with approving homemade
software versions. In the past I've updated Wildfly with newer releases
Artemis jars to address other issues and have gotten that method approved but I
think that's about as far as they're willing to go. That's why I was hoping
maybe the 1.6 version could include this fix and I would be able to simply drop
the jars into Wildfly. Otherwise we'll probably need to wait until Wildfly 14
or whatever version includes the fix.
> 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.6.0
> Reporter: Paweł Puterla
> Assignee: Justin Bertram
> Priority: Major
> Fix For: 2.7.0, 2.6.1
>
>
> 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)
