几分钟后，弹簧靴踩断了连接

Question

我用的是ActiveMQ Artemis，SockJS，StompJS，。建立连接时，客户端发送心跳信息：

<<< CONNECTED
version:1.1
session:1913360c
server:ActiveMQ-Artemis/2.20.0 ActiveMQ Artemis Messaging Engine
heart-beat:10000,10000
user-name:qqq

心跳正常，但几分钟后连接被ActiveMQ关闭。下面是相应的日志：

2022-03-03 09:30:09,718 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client /127.0.0.1:1432: AMQ229014: Did not receive data from /127.0.0.1:1432 within the 20,000ms connection TTL. The connection will now be closed.
2022-03-03 09:30:09,719 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ229014: Did not receive data from /127.0.0.1:1432 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
2022-03-03 09:30:09,719 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session aa0cdab7-9a90-11ec-8b3d-6c02e05f997e
2022-03-03 09:30:09,725 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session aa0cdab7-9a90-11ec-8b3d-6c02e05f997e
2022-03-03 09:58:45,120 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client /127.0.0.1:1922: AMQ229014: Did not receive data from /127.0.0.1:1922 within the 20,000ms connection TTL. The connection will now be closed.
2022-03-03 09:58:45,122 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ229014: Did not receive data from /127.0.0.1:1922 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
2022-03-03 09:58:45,122 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session d2309f42-9a91-11ec-8b3d-6c02e05f997e
2022-03-03 09:58:45,125 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session d2309f42-9a91-11ec-8b3d-6c02e05f997e
2022-03-03 10:14:16,758 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client /127.0.0.1:4003: AMQ229014: Did not receive data from /127.0.0.1:4003 within the 20,000ms connection TTL. The connection will now be closed.
2022-03-03 10:14:16,759 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ229014: Did not receive data from /127.0.0.1:4003 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
2022-03-03 10:14:16,759 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 939d58fd-9a95-11ec-8b3d-6c02e05f997e
2022-03-03 10:14:16,763 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session 939d58fd-9a95-11ec-8b3d-6c02e05f997e
2022-03-03 10:14:53,112 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client null: null
2022-03-03 10:14:53,113 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: null [code=REMOTE_DISCONNECT]
2022-03-03 10:14:53,123 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client null: null
2022-03-03 10:14:53,123 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: null [code=REMOTE_DISCONNECT]
2022-03-03 10:21:34,506 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client /127.0.0.1:5140: AMQ229014: Did not receive data from /127.0.0.1:5140 within the 20,000ms connection TTL. The connection will now be closed.
2022-03-03 10:21:34,506 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ229014: Did not receive data from /127.0.0.1:5140 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
2022-03-03 10:21:34,507 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session ce63aa1a-9a97-11ec-8b3d-6c02e05f997e
2022-03-03 10:21:34,510 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session ce63aa1a-9a97-11ec-8b3d-6c02e05f997e
2022-03-03 11:21:29,133 WARN  [org.apache.activemq.artemis.core.protocol.stomp] AMQ332069: Sent ERROR frame to STOMP client /127.0.0.1:5582: AMQ229014: Did not receive data from /127.0.0.1:5582 within the 20,000ms connection TTL. The connection will now be closed.
2022-03-03 11:21:29,134 WARN  [org.apache.activemq.artemis.core.server] AMQ222067: Connection failure has been detected: AMQ229014: Did not receive data from /127.0.0.1:5582 within the 20,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
2022-03-03 11:21:29,134 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session d1631205-9a98-11ec-8b3d-6c02e05f997e
2022-03-03 11:21:29,137 WARN  [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session d1631205-9a98-11ec-8b3d-6c02e05f997e

我试了几次，当最后一次连接丢失时，立即刷新。它看起来很奇怪，有时连接可以维持半个小时，有时只是几分钟。

java代码：

    @Override
    protected void configureStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws").withSockJS();
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        //registry.enableSimpleBroker("/queue/", "/topic/", "/exchange/");
        registry.enableStompBrokerRelay("/queue/", "/topic/", "/exchange/")
                .setSystemHeartbeatSendInterval(20000)
                .setSystemHeartbeatReceiveInterval(20000)
                .setTaskScheduler(heartBeatScheduler())
                
                .setRelayHost("127.0.0.1")
                .setRelayPort(61613)
                .setClientLogin("mirana")
                .setClientPasscode("mirana")
                .setSystemLogin("mirana")
                .setSystemPasscode("mirana");
        registry.setApplicationDestinationPrefixes("/app");
    }


  
    @Bean
    @Primary
    public UserDestinationResolver destinationResolver(SimpUserRegistry simpUserRegistry){
        return new DefaultUserDestinationResolver(simpUserRegistry){
            @Override
            public String getTargetDestination(String sourceDestination, String actualDestination,
                    String sessionId, @Nullable String user){
                return actualDestination + "-user-" + user;
            }
        };
    }

    @Bean
    public TaskScheduler heartBeatScheduler() {
        return new ThreadPoolTaskScheduler();
    }

server.js

import Stomp from 'stompjs'
import Sockjs from 'sockjs-client'

var stompClient;

export function init(url){
    stompClient = Stomp.over(new Sockjs(url))
}


export function connect(successCallback, errorCallback){
    stompClient.connect({}, function(frame){
        successCallback(frame)
    }, function(frame){
        errorCallback(frame)
    })
}


export function subscribe(destination, callback){
    stompClient.subscribe(destination, message => callback(message))
}

export function send(destination, headers, object){
    stompClient.send(destination,headers,object)
}

client.js

server.init('http://localhost:9999/ws?type=1&id=321feead21313fesa')
    server.connect(frame =>{
      console.log(frame)
      server.subscribe('/topic/chat.typing', message => {
        console.log("chat.type"+message)
      })
      server.subscribe('/topic/chat.message', message => {
        console.log("chat.message"+message)
      })
    }, frame =>{
      console.log(frame)
    })
}

为什么失去的连接间隔是不同的？我很困惑。

我用的是本地主机，而不是广域网或局域网。

我将日志级别设置为TRACE，服务器在20多个小时内不接收来自客户端的心跳(每次心跳为10s )，然后代理关闭了连接。所以也许这是客户的问题。也许有CPU尖峰。这可能需要更多的测试才能找到问题。

我试图检查客户端，当连接丢失时，状态代码为1002，这意味着an endpoint is terminating the connection due to a protocol error。有人知道如何解决这个问题吗。

Answer 1

您的意见不符合STOMP规范。如果客户端不能根据它在heart-beat帧的CONNECT头中发送的值来保证心跳，那么它应该发送一个不同的值。在你的情况下，你是派10000为客户心跳。因此，根据这个值，代理将期望客户的心脏跳动，如果它没有接收到这些心跳，那么它将断开客户端的连接。如果你不希望客户发送心跳，那么你应该发送0，例如heart-beat:0,10000。

此外，代理报告说，它在“20,000‘s”之后关闭了客户端的连接，因为默认情况下，它将通过2 (例如10000 * 2 = 20000)将客户机心跳值乘以。它之所以这样做，是因为踩踏规格建议为计时错误添加一个空白：

由于定时不准确，接收方应该宽容，并考虑到误差。