bifromqio / bifromq Goto Github PK

百度BifroMQ 团队你们好, 看了下官方关于BifroMQ 的文档, 里面没有关于任何规则引擎的介绍, 请问BifroMQ 是不是不支持规则引擎呢? 谢谢

bifromq 性能测试可能阻塞点
3台节点组成 bifromq 集群，连接了 4w client，每个 client 发送 4k 的 body， 集群的 direct memory 很快就满了然后集群就宕机了。我们抓了正常压测下的集群 bootstrap 节点的 off-cpu 火焰图（arthas 抓取 event type 为 lock 的火焰图），发现可能的阻塞点可能在DistWorkerCoProcFactory的 ForkJoinPool ，98%的时间是在 ForkJoinPool 上。

Netty 网络收发只占了 2% 时间不到

BifroMQ

• Version: 2.1.1

大佬，能否支持内置规则引擎推送数据到RocketMQ。

Describe the bug

前一日压测场景:10Topic_10P_10S_Qos0_Payload5120_Qps13030.2_cleanSession=True_Retain=false
压测工具:jmeter
bifromq version: 2.1.0
● 发压机: 云服务器 CentOS Linux release 7.9.2009 (Core) 8核 16GB
● 部署机: 云服务器 CentOS Linux release 7.9.2009 (Core) 8核 16GB * 3
● 订阅机: 云服务器 CentOS Linux release 7.9.2009 (Core) 8核 16GB

nginx 配置
stream { upstream bifromq_cluster{ #least_conn; server 172.16.32.3:1883; server 172.16.32.4:1883; server 172.16.32.7:1883; #server bifromq-node1:1883; } server { listen 1884 so_keepalive=on; proxy_connect_timeout 60s; #proxy_timeout 60s; proxy_pass bifromq_cluster; tcp_nodelay on; # nginx 不限速 #limit_rate 50g; } }

standalone.yml 配置

bifromq-start.sh 配置

error 错误日志

Problem

It seems unnecessary to enable checkpoint mechanism for KVRange's WAL usage scenario, which leads to many unused disk files get pinned for long time.

Possible Solution

Refactoring the type hierarchy of basekv-local-engine based on current usage scenarios, and optimize the disk usage

rt

Console not found，When to support

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
In cluster mode, shutting down a BifroMQ node may result in the possibility of MQTT connections on other nodes being kicked off.

Logs
event log： KICKED

BifroMQ

• Version: v2.1

Is your feature request related to a problem? Please describe.
Hello, is there a way to configure the broker to forward the user credentials and the mqtt messages to an http endpoint via webhook?

Describe the solution you'd like
We basically uses a Nodejs endpoint that authenticates user over JWT (broker sends to endpoint the username field onAuth svent) and also receives incoming mqtt messages' payload (onPublish) to take action accordingly.

Describe alternatives you've considered
We currently use Vernemq broker to enjoy above feature, but would like to test bifromq if these features were available.

BifroMQ can handle MQTT5 CONNECT Packet with all flags except Will message

使用5台机器构成mqtt集群，机器配置均为128G 内存 32核CPU，局域网环境，网络资源足够，使用28万连接的200B payload，7万连接100K的payload，大小包均为每5秒发送一次数据，持续运行30分钟后，服务器出现大量CLOSE_WAIT tcp连接，客户端也无法连接mqtt，整体过程负载不高 只使用了1/3的负载。
配置参数在下面有，我们期望压测将CPU打上去，是集群能够承受更多的大payload连接。

*** PUB Client ***:

• MQTT Connection:
  • Clean Session: true
• MQTT Pub:
  • Topic: 100个topic
  • QoS: 0
  • Retain: false
    *** SUB Client ***
    无SUB

Logs
无错误日志

HOST

• CPU: 16
• Memory: 32G
• Number: 7

OS(please complete the following information):

• OS: centos 7
• Kernel Version [e.g. 5.6]
  • Kernel Specific Settings: [e.g. TCP, FD, etc]

JVM:

• Version: 17
• Arguments:
  java -Xms32042m -Xmx64084m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=500m -XX:MaxDirectMemorySize=40318643400 -server -XX:MaxInlineLevel=15 -Djava.awt.headless=true -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+UseZGC -XX:ZAllocationSpikeTolerance=5 -Xlog:async -Xlog:gc:file=/data2/bifromq-2.0.1/bin/../logs/gc-%t.log:time,tid,tags:filecount=5,filesize=50m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data2/bifromq-2.0.1/bin/../logs -Dinbox_store_range_voter_count=5 -Ddist_worker_range_voter_count=5 -Dretain_store_range_voter_count=5 -cp /data2/bifromq-2.0.1/bin/../lib/* -DLOG_DIR=/data2/bifromq-2.0.1/bin/../logs -DCONF_DIR=/data2/bifromq-2.0.1/bin/../conf -DDATA_DIR=/data2/bifromq-2.0.1/bin/../data -DBIND_ADDR=10.89.144.26 -Dlogback.configurationFile=/data2/bifromq-2.0.1/bin/../conf/logback.xml -Dpf4j.pluginsDir=/data2/bifromq-2.0.1/bin/../plugins com.baidu.bifromq.starter.StandaloneStarter -c /data2/bifromq-2.0.1/bin/../conf/standalone.yml

BifroMQ

• Version: bifromq-2.0.1
• Non-Default Configuration:

mqttServerConfig:
tcpListener:
port: 1883
connTimeoutSec: 5
maxConnPerSec: 3000
defaultKeepAliveSec: 60

tlsListener:
enable: true
host:
port: 8883
sslConfig:
certFile: server.crt
keyFile: server_pkcs8.key
trustCertsFile: root.crt
clientAuth: REQUIRE
rpcClientConfig:
workerThreads: 100

rpcServerConfig:
workerThreads: 100

baseKVRpcServerConfig:
workerThreads: 100

stateStoreConfig:
queryThreads: 100
bgWorkerThreads: 100
tickerThreads: 10
distWorkerConfig:
queryPipelinePerStore: 10000
compactWALThreshold: 5000
inboxStoreConfig:
queryPipelinePerStore: 10000

Additional context
集群为5台

本地开发如何搭建环境？bifromq 2.1.0版本，出现class not found。

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

在开发bifrom auth 插件时发现，重写IAuthProvider 下auth(MQTT5AuthData authData)方法后，mqtt5 auth方法在建立连接时并未生效。而是会一直走auth(MQTT3AuthData mqtt3AuthData) 方法。
bifromq version:3.0.0-beta.1

Describe the bug

To Reproduce
使用同一个http client持续向BifroMQ发送多个tenantId的消息，较长时间后会出现此问题。

Describe the bug

问题：构建成功后的集群，主节点可以连接，从节点不可连接。

三个节点均打印了构建集群成功的日志
`2024-05-09 12:15:40.685 INFO [ForkJoinPool.commonPool-worker-1] --- c.b.bifromq.starter.StandaloneStarter [StandaloneStarter.java:217] AgentHost joined seedEndpoint: b1:18899,b2:18899,b3:18899
2024-05-09 12:16:26.250 INFO [main] --- c.b.bifromq.starter.StandaloneStarter [StandaloneStarter.java:557] Standalone broker started

`

Expected behavior
A clear and concise description of what you expected to happen.

Logs
三个节点日志

HOST

• CPU: 2C4G
• Memory: [e.g. 32G]

OS(please complete the following information):

• OS: Rocky Linux 9.3 Docker

JVM:

• Version: [e.g. 17]
• Arguments: [e.g. if override any JVM arguments]

BifroMQ

• Version: bifromq-3.0.2

Describe the bug
We are set Setting Provider plugin code
@extension
@slf4j
public class SettingProvider implements ISettingProvider {

@Override
public <R> R provide(Setting setting, String tenantId) {
    if (setting == Setting.DebugModeEnabled) {
        Boolean r = checkDebugMode(tenantId);
        log.info("Debug mode for tenant {} is {}", tenantId, r);
        return (R) r;
    }else if(setting==Setting.MQTT3Enabled){
        log.info("MQTT3Enabled for tenant {} is {}", tenantId, false);
        return (R) Boolean.valueOf(false);

    }
    return setting.current(tenantId);
}

}
setting MQTT3Enabled for false ,than use client protocol 3 connect success

Debug code SettingProviderManager.java

public R provide(Setting setting, String tenantId) {
assert !stopped.get();
R current = setting.current(tenantId);
try {
Timer.Sample sample = Timer.start();
R newVal = provider.provide(setting, tenantId);
sample.stop(provideCallTimer);
if (setting.isValid(newVal)) {
// update the value
setting.current(tenantId, newVal);
} else {
log.warn("Invalid setting value: setting={}, value={}", setting.name(), newVal);
}
} catch (Throwable e) {
log.error("Setting provider throws exception: setting={}", setting.name(), e);
// keep current value in case provider throws
setting.current(tenantId, current);
provideCallErrorCounter.increment();
}
return current;
}

newVal is my Setting Provider value for false is right,but last return current is default value to true. Whether to return newVal?

public TenantSettings(String tenantId, ISettingProvider provider) {
mqtt3Enabled = provider.provide(MQTT3Enabled, tenantId);
mqtt4Enabled = provider.provide(MQTT4Enabled, tenantId);
mqtt5Enabled = provider.provide(MQTT5Enabled, tenantId);
}

JVM:

• Version: [e.g. 17]
• Arguments: [e.g. if override any JVM arguments]

BifroMQ

• Version: 3.0
• Non-Default Configuration:

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Problem

In JWT-like authn/authz mechanisms, some forms of ACLs are directly embedded in the token. This information will be used during pub/sub for access control. In the current workflow, the ClientInfo of each session, which is populated after a successful connection, only contains limited reserved metadata. This makes the implementation of JWT-based auth provider plugins really challenging.

Possible solution

1. Enhance the OK proto (the returned type when the connecting client passes authentication) to allow the passing of additional implementation-specific attributes describing the current authenticated client. In the JWT case, the ACLs will be attached as additional attributes.
2. Populate the ClientInfo with these attributes as part of the metadata, ensuring the reserved metadata is not overridden. In the JWT case, the ACLs information will be treated as metadata and used in pub/sub permission checking, which can likely be done locally without the need for remote calls.

Notes

• There is no limit on the size of the attributes passed back from the auth provider plugin via the OK structure. It is the responsibility of the plugin implementer to keep the attributes compact and memory-efficient.

使用JDK21编译 bifromq (tag v3.0.2) 会出现“NoSuchFieldError 'com.sun.tools.javac.tree.JCTree qualid' ” 错误。

解决方案：
1、在 bifromq-parent 的pom.xml 中升级 => <lombok.version>1.18.30</lombok.version>
2、在base-hookloader和base-env-provider中的pom.xml 中添加

 <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
    </dependency>

Great work in opensousing a capable MQTT broker.
Any plans to launch MQTT 5 support?

Thanks

Dist 模块 dataEngineConfig.type 为 rocksdb 时，qos0 发送性能比 dataEngineConfig 为 memory 差很多
我们在测试 qos0 发送性能，集群 3个节点，4w 个 client （cleansession=true），每个 client 订阅 3个 topic，然后固定向自己的一个 topic (类似 xx/${client-id}/send) 发送 QOS 0 消息，没有client 订阅这些消息，当配置 distWorkerConfig.dataEngineConfig.type = rocksdb 时，性能比 memory 要差很多，当 message 比较大时，很容易将 direct memory 打满然后宕机。其中发现了 2个可能的异常
监控指标 basekv_le_call_time_seconds_count{op="metadata"} 和 basekv_le_call_time_seconds_count{op="refresh"}，它们随请求数同步增长，理论上 QOS 0 消息应该不会持久化保存，为啥还是会去读写 rocksdb呢？另一个监控指标 dist_match_internal 很小，dist_match_external 很大，说明 Dist 模块的 SubscriptionCache 缓存命中率很高
监控指标 basekv_le_call_time_seconds_count{op="metadata"}

监控指标 mqtt_ingress_qos0_bytes_count

*** PUB Client ***:

• MQTT Connection:
  • Clean Session: true
  • ClientIdentifier:
• MQTT Pub:
  • QoS: 0
  • Retain: false
    *** SUB Client ***
• MQTT Connection:
  • Clean Session: true

HOST

• CPU: 2C
• Memory: 4G

JVM:

• Version: 17
• Arguments: [e.g. if override any JVM arguments]

BifroMQ

• Version: 2.1.1
• Non-Default Configuration:
  stateStoreConfig:
  distWorkerConfig:
  walEngineConfig:
  type: rocksdb
  asyncWALFlush: true
  dataEngineConfig:
  type: rocksdb
  asyncWALFlush: true

Currently, bifromq logs the initial configuration at the start of the program, which is very helpful.
However, it would be even more beneficial if the log could also include JVM parameters and initial settings.
This enhancement would provide a more comprehensive overview of the runtime environment, aiding in troubleshooting and configuration analysis.

Describe the bug
在使用jmete进行压测时发现。使用jmeter一个线程qos0(body中存在顺序递增seq)，向一个topic中发送消息，Sub也是唯一订阅者消费。在观察sub端打印日志时发现，打印出的seq并不是顺序递增的，而是会出现乱序的情况。

*** Pub Client ***
Jmeter 配置

*** SUB Client ***

• centos 7
• CPU: 4
• Memory: 4G
  采用java 进行接收

       <dependency>
            <groupId>org.eclipse.paho</groupId>
            <artifactId>org.eclipse.paho.client.mqttv3</artifactId>
            <version>1.2.5</version>
        </dependency>

• MQTT Connection:
  • Clean Session: false
  • ClientIdentifier:
  • etc...
• MQTT Sub:
  • TopicFilter: mqtt_test_local_1
  • QoS: 0

Logs
出现如图所示 seq乱序情况

** biformq 集群**
集群采用k8s部署，4核10g *3

JVM:

• Version: 17

BifroMQ

• Version: 2.1.0
• Non-Default Configuration:
• bifromq-start.sh -server -DMsgPubPerSec=100000 -DInBoundBandWidth=1073741824 -DOutBoundBandWidth=1073741824
• standalone.yml

#edit
mqttServerConfig:
  tcpListener:
    port: 1883
  maxMsgByteSize: 1048576
  maxConnBandwidth: 1073741824
  maxConnPerSec: 5000

后序发现在windows搭建本地bifromq 单机版也能复现该问题。

Describe the bug
客户端订阅了 /v1/devices/1036150750765057/command ，接收不到消息
和协议版本无关，3.1.1和5.0都有这个问题

调用 /pub API：
入参
{ "clientType": "web", "expirySeconds": "3600", "payload": "{\"head\":{\"cipherFlag\":0,\"timeStamp\":1713414003773},\"dataBody\":{\"msgType\":\"cloudReq\",\"serviceCode\":\"default_brightness_controls\",\"productIdentification\":\"5282358452289536\",\"cmd\":\"brightness_level_regulate\",\"deviceIdentification\":\"1036150750765057\",\"params\":{\"luminance\":\"111\"}},\"dataSign\":\"feeb5ca02d79dc42296760a7cf5049e3\"}", "qos": "2", "reqId": 1837295270338560, "tenantId": "1", "topic": "/v1/devices/1036150750765057/command" }

bifromq Response：<200 OK OK,OK,[content-length:"2", req_id:"1837295270338560"]>

To Reproduce

客户端正常订阅了此主题

Expected behavior
调用api推送消息，客户端订阅收不到

Logs

2024-04-18 02:29:28.340 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-1 2024-04-18 02:29:28.340 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-2 2024-04-18 02:29:28.340 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-2 2024-04-18 02:29:28.340 WARN [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type UNMATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 02:29:28.340 WARN [TaskQueueThread-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type UNMATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 02:29:28.340 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-4 2024-04-18 02:29:28.340 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-1 2024-04-18 02:29:28.340 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-4 2024-04-18 02:29:28.340 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-1 2024-04-18 02:33:28.501 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.Metadata [Metadata.java:408] [Producer clientId=producer-1] Resetting the last seen epoch of partition mqtt.distribution.completed.topic-0 to 0 since the associated topicId changed from null to 8-Nuv34fT3qc0aaG53KWCQ 2024-04-18 02:33:28.501 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.Metadata [Metadata.java:408] [Producer clientId=producer-1] Resetting the last seen epoch of partition mqtt.subscription.acked.topic-0 to 0 since the associated topicId changed from null to HxVZQaKFQDiie05VcZxwYw 2024-04-18 02:33:28.501 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.Metadata [Metadata.java:408] [Producer clientId=producer-1] Resetting the last seen epoch of partition mqtt.client.connected.topic-0 to 0 since the associated topicId changed from null to ad-GBqZOSB2MeBbKPVwhig 2024-04-18 02:37:28.713 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.NetworkClient [NetworkClient.java:977] [Producer clientId=producer-1] Node -1 disconnected. 2024-04-18 04:19:48.686 INFO [mqtt-worker-elg-1] --- bifromq.plugin.provider.AuthProvider [AuthProvider.java:77] Authenticating client - clientId: 1036150750765056@1, username: 123456, password: 123456 2024-04-18 04:19:48.800 INFO [pool-2-thread-2] --- bifromq.plugin.provider.AuthProvider [AuthProvider.java:103] Authentication response - statusCode: 200, responseBody: {"id":null,"createdTime":null,"createdBy":null,"updatedTime":null,"updatedBy":null,"echoMap":null,"certificationResult":true,"errorMessage":null,"deviceResult":{"id":"470808946278400017","createdTime":"2024-03-19 17:00:10","createdBy":"1452186486253289472","updatedTime":"2024-03-19 17:00:10","updatedBy":"1452186486253289472","echoMap":{},"clientId":"1036150750765056@1","userName":"123456","password":"123456","appId":"thinglinks-test","authMode":0,"encryptKey":"","encryptVector":"","signKey":"123","encryptMethod":0,"deviceIdentification":"1036150750765057","deviceName":"??????A1","connector":"broker.thinglinks.mqttsnet.com:11883","description":"","deviceStatus":1,"connectStatus":2,"deviceTags":"","productIdentification":"5282358452289536","swVersion":"v1","fwVersion":"v1","deviceSdkVersion":"v1","gatewayId":null,"nodeType":1,"remark":"","createdOrgId":null,"productResultVO":null,"deviceLocationResultVO":null},"tenantId":"1"} 2024-04-18 04:19:48.800 INFO [pool-2-thread-2] --- bifromq.plugin.provider.AuthProvider [AuthProvider.java:123] Authentication successful - clientId: 1036150750765056@1, tenantId: 1 2024-04-18 04:19:48.809 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:48.810 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-3 2024-04-18 04:19:48.810 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'CLIENT_CONNECTED'. Time: 1713413988810 2024-04-18 04:19:48.810 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: CLIENT_CONNECTED 2024-04-18 04:19:48.813 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.client.connected.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","keepAliveTimeSeconds":60,"event":"connect","timestamp":1713413988810} 2024-04-18 04:19:48.813 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: CLIENT_CONNECTED 2024-04-18 04:19:48.813 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'CLIENT_CONNECTED'. Duration: 3 ms 2024-04-18 04:19:48.813 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-3 2024-04-18 04:19:48.813 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-3 2024-04-18 04:19:48.816 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.client.connected.topic. 2024-04-18 04:19:48.816 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.client.connected.topic,end 2024-04-18 04:19:48.931 INFO [basekv-client-executor-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:48.931 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-2 2024-04-18 04:19:48.931 WARN [TaskQueueThread-2] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type MATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 04:19:48.932 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-2 2024-04-18 04:19:48.932 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-2 2024-04-18 04:19:48.934 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:48.934 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-4 2024-04-18 04:19:48.934 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'SUB_ACKED'. Time: 1713413988934 2024-04-18 04:19:48.934 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: SUB_ACKED 2024-04-18 04:19:48.936 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.subscription.acked.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","messageId":48800,"topic":"/v1/devices/1106781324582913/dataResponse","event":"SUBSCRIBE","timestamp":1713413988934} 2024-04-18 04:19:48.936 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: SUB_ACKED 2024-04-18 04:19:48.936 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'SUB_ACKED'. Duration: 2 ms 2024-04-18 04:19:48.936 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-4 2024-04-18 04:19:48.936 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-4 2024-04-18 04:19:48.938 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.subscription.acked.topic. 2024-04-18 04:19:48.938 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.subscription.acked.topic,end 2024-04-18 04:19:49.030 INFO [basekv-client-executor-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.031 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-1 2024-04-18 04:19:49.031 WARN [TaskQueueThread-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type MATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 04:19:49.031 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-1 2024-04-18 04:19:49.031 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-1 2024-04-18 04:19:49.032 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.032 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-3 2024-04-18 04:19:49.032 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'SUB_ACKED'. Time: 1713413989032 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: SUB_ACKED 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.subscription.acked.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","messageId":48801,"topic":"/v1/devices/3160832883650561/topo/addResponse","event":"SUBSCRIBE","timestamp":1713413989033} 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: SUB_ACKED 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'SUB_ACKED'. Duration: 1 ms 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-3 2024-04-18 04:19:49.033 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-3 2024-04-18 04:19:49.035 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.subscription.acked.topic. 2024-04-18 04:19:49.035 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.subscription.acked.topic,end 2024-04-18 04:19:49.130 INFO [basekv-client-executor-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.131 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-2 2024-04-18 04:19:49.131 WARN [TaskQueueThread-2] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type MATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 04:19:49.131 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-2 2024-04-18 04:19:49.131 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-2 2024-04-18 04:19:49.133 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.133 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-4 2024-04-18 04:19:49.133 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'SUB_ACKED'. Time: 1713413989133 2024-04-18 04:19:49.133 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: SUB_ACKED 2024-04-18 04:19:49.134 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.subscription.acked.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","messageId":48802,"topic":"/v1/devices/3160832883650561/topo/updateResponse","event":"SUBSCRIBE","timestamp":1713413989133} 2024-04-18 04:19:49.134 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: SUB_ACKED 2024-04-18 04:19:49.134 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'SUB_ACKED'. Duration: 1 ms 2024-04-18 04:19:49.134 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-4 2024-04-18 04:19:49.134 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-4 2024-04-18 04:19:49.136 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.subscription.acked.topic. 2024-04-18 04:19:49.136 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.subscription.acked.topic,end 2024-04-18 04:19:49.232 INFO [basekv-client-executor-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.233 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-1 2024-04-18 04:19:49.233 WARN [TaskQueueThread-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type MATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 04:19:49.233 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-1 2024-04-18 04:19:49.233 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-1 2024-04-18 04:19:49.235 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.235 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-3 2024-04-18 04:19:49.235 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'SUB_ACKED'. Time: 1713413989235 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: SUB_ACKED 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.subscription.acked.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","messageId":48803,"topic":"/v1/devices/3160832883650561/topo/queryResponse","event":"SUBSCRIBE","timestamp":1713413989236} 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: SUB_ACKED 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'SUB_ACKED'. Duration: 1 ms 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-3 2024-04-18 04:19:49.236 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-3 2024-04-18 04:19:49.244 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.subscription.acked.topic. 2024-04-18 04:19:49.244 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.subscription.acked.topic,end 2024-04-18 04:19:49.336 INFO [basekv-client-executor-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.336 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-2 2024-04-18 04:19:49.336 WARN [TaskQueueThread-2] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type MATCHED as no mapping exists in TOPIC_MAP. 2024-04-18 04:19:49.336 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-2 2024-04-18 04:19:49.336 INFO [TaskQueueThread-2] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-2 2024-04-18 04:19:49.338 INFO [mqtt-worker-elg-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-4 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'SUB_ACKED'. Time: 1713413989338 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: SUB_ACKED 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.subscription.acked.topic: {"clientId":"1036150750765056@1","address":"/111.202.125.68:11173","success":"success","tenantId":"1","messageId":48804,"topic":"/v1/devices/1036150750765057/command","event":"SUBSCRIBE","timestamp":1713413989338} 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: SUB_ACKED 2024-04-18 04:19:49.338 INFO [TaskQueueThread-4] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'SUB_ACKED'. Duration: 0 ms 2024-04-18 04:19:49.339 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-4 2024-04-18 04:19:49.339 INFO [TaskQueueThread-4] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-4 2024-04-18 04:19:49.341 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.subscription.acked.topic. 2024-04-18 04:19:49.341 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.subscription.acked.topic,end 2024-04-18 04:20:04.137 INFO [topic-matcher-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:20:04.137 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-1 2024-04-18 04:20:04.137 WARN [TaskQueueThread-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:101] Discarding events of type DELIVERED as no mapping exists in TOPIC_MAP. 2024-04-18 04:20:04.137 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-1 2024-04-18 04:20:04.137 INFO [TaskQueueThread-1] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-1 2024-04-18 04:20:04.138 INFO [basekv-client-executor] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:67] Adding new task... 2024-04-18 04:20:04.138 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:48] Beginning task execution on thread: TaskQueueThread-3 2024-04-18 04:20:04.138 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:140] Starting execution of event: 'DISTED'. Time: 1713414004138 2024-04-18 04:20:04.138 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:151] Processing event type: DISTED 2024-04-18 04:20:04.140 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:159] Sent to Kafka topic mqtt.distribution.completed.topic: {"expiryInterval":3600,"qos":2,"payload":"{\"head\":{\"cipherFlag\":0,\"timeStamp\":1713414003773},\"dataBody\":{\"msgType\":\"cloudReq\",\"serviceCode\":\"default_brightness_controls\",\"productIdentification\":\"5282358452289536\",\"cmd\":\"brightness_level_regulate\",\"deviceIdentification\":\"1036150750765057\",\"params\":{\"luminance\":\"111\"}},\"dataSign\":\"feeb5ca02d79dc42296760a7cf5049e3\"}","tenantId":"1","topic":"/v1/devices/1036150750765057/command","messageId":0,"time":0,"event":"PUBLISH","body":"{\"head\":{\"cipherFlag\":0,\"timeStamp\":1713414003773},\"dataBody\":{\"msgType\":\"cloudReq\",\"serviceCode\":\"default_brightness_controls\",\"productIdentification\":\"5282358452289536\",\"cmd\":\"brightness_level_regulate\",\"deviceIdentification\":\"1036150750765057\",\"params\":{\"luminance\":\"111\"}},\"dataSign\":\"feeb5ca02d79dc42296760a7cf5049e3\"}","timestamp":0} 2024-04-18 04:20:04.140 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:164] Processed event type: DISTED 2024-04-18 04:20:04.140 INFO [TaskQueueThread-3] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:147] Completed execution of event: 'DISTED'. Duration: 2 ms 2024-04-18 04:20:04.140 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:50] Task execution completed on thread: TaskQueueThread-3 2024-04-18 04:20:04.140 INFO [TaskQueueThread-3] --- bifromq.plugin.utils.TaskQueue [TaskQueue.java:46] Waiting for task, executing on thread: TaskQueueThread-3 2024-04-18 04:20:04.147 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:436] Message successfully sent to topic mqtt.distribution.completed.topic. 2024-04-18 04:20:04.147 INFO [kafka-producer-network-thread | producer-1] --- b.plugin.provider.EventKafkaProvider [EventKafkaProvider.java:438] topic:mqtt.distribution.completed.topic,end 2024-04-18 04:22:29.259 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.Metadata [Metadata.java:408] [Producer clientId=producer-1] Resetting the last seen epoch of partition mqtt.subscription.acked.topic-0 to 0 since the associated topicId changed from null to HxVZQaKFQDiie05VcZxwYw 2024-04-18 04:22:29.260 INFO [kafka-producer-network-thread | producer-1] --- org.apache.kafka.clients.Metadata [Metadata.java:408] [Producer clientId=producer-1] Resetting the last seen epoch of partition mqtt.client.connected.topic-0 to 0 since the associated topicId changed from null to ad-GBqZOSB2MeBbKPVwhig

HOST

• CPU: [e.g. vCPU 8]
• Memory: [e.g. 16G]

OS(please complete the following information):

• OS: CentOS 7
• Kernel Version [e.g. 5.6]
  • Kernel Specific Settings: [e.g. TCP, FD, etc]

JVM:

• Version: [e.g. 17]

BifroMQ

• Version: Docker 3.0.0
• Non-Default Configuration:

插件是基于3.0.0重新编译的，代码是bifromq2.0正常使用的，所以和插件无关

Additional context

info：
2024-04-18 02:28:29.997 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: distservice.DistService 2024-04-18 02:28:30.204 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: inboxservice.InboxService 2024-04-18 02:28:30.405 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: sessiondict.SessionDictService 2024-04-18 02:28:30.606 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: mqttbroker.OnlineInboxBroker 2024-04-18 02:28:30.808 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: retainservice.RetainService 2024-04-18 02:28:31.010 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: [email protected] 2024-04-18 02:28:31.211 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: [email protected] 2024-04-18 02:28:31.412 INFO [main] --- com.baidu.bifromq.baserpc.RPCServer [RPCServer.java:179] Start server register for service: [email protected] 2024-04-18 02:28:31.616 INFO [main] --- c.baidu.bifromq.mqtt.AbstractMQTTBroker [AbstractMQTTBroker.java:98] Starting MQTT broker 2024-04-18 02:28:31.618 INFO [main] --- c.baidu.bifromq.mqtt.AbstractMQTTBroker [AbstractMQTTBroker.java:121] MQTT broker started 2024-04-18 02:28:31.618 INFO [main] --- com.baidu.bifromq.apiserver.APIServer [APIServer.java:108] Starting API server 2024-04-18 02:28:31.618 INFO [main] --- com.baidu.bifromq.apiserver.APIServer [APIServer.java:115] API server started 2024-04-18 02:28:36.429 INFO [main] --- c.b.bifromq.starter.StandaloneStarter [StandaloneStarter.java:557] Standalone broker started

gc：
[2024-04-18T02:28:26.762+0000][64][gc] Using The Z Garbage Collector [2024-04-18T02:28:28.765+0000][69][gc] GC(0) Garbage Collection (Warmup) 234M(11%)->84M(4%) [2024-04-18T02:32:26.032+0000][69][gc] GC(1) Garbage Collection (Warmup) 410M(20%)->112M(5%) [2024-04-18T03:01:17.606+0000][69][gc] GC(2) Garbage Collection (Warmup) 616M(30%)->112M(5%) [2024-04-18T03:06:17.789+0000][69][gc] GC(3) Garbage Collection (Proactive) 202M(10%)->106M(5%) [2024-04-18T03:11:17.963+0000][69][gc] GC(4) Garbage Collection (Proactive) 204M(10%)->108M(5%) [2024-04-18T03:16:18.066+0000][69][gc] GC(5) Garbage Collection (Proactive) 202M(10%)->104M(5%) [2024-04-18T03:21:18.163+0000][69][gc] GC(6) Garbage Collection (Proactive) 210M(10%)->100M(5%) [2024-04-18T03:26:18.260+0000][69][gc] GC(7) Garbage Collection (Proactive) 206M(10%)->102M(5%) [2024-04-18T03:31:18.357+0000][69][gc] GC(8) Garbage Collection (Proactive) 208M(10%)->104M(5%) [2024-04-18T03:36:18.458+0000][69][gc] GC(9) Garbage Collection (Proactive) 208M(10%)->106M(5%) [2024-04-18T03:41:18.556+0000][69][gc] GC(10) Garbage Collection (Proactive) 210M(10%)->106M(5%) [2024-04-18T03:46:18.657+0000][69][gc] GC(11) Garbage Collection (Proactive) 208M(10%)->104M(5%) [2024-04-18T03:51:18.761+0000][69][gc] GC(12) Garbage Collection (Proactive) 212M(10%)->102M(5%) [2024-04-18T03:56:18.862+0000][69][gc] GC(13) Garbage Collection (Proactive) 212M(10%)->100M(5%) [2024-04-18T04:01:18.958+0000][69][gc] GC(14) Garbage Collection (Proactive) 216M(11%)->106M(5%) [2024-04-18T04:06:19.060+0000][69][gc] GC(15) Garbage Collection (Proactive) 212M(10%)->100M(5%) [2024-04-18T04:11:19.157+0000][69][gc] GC(16) Garbage Collection (Proactive) 218M(11%)->102M(5%) [2024-04-18T04:16:19.263+0000][69][gc] GC(17) Garbage Collection (Proactive) 216M(11%)->100M(5%) [2024-04-18T04:21:19.360+0000][69][gc] GC(18) Garbage Collection (Proactive) 228M(11%)->102M(5%) [2024-04-18T04:26:19.468+0000][69][gc] GC(19) Garbage Collection (Proactive) 220M(11%)->108M(5%) [2024-04-18T04:31:19.558+0000][69][gc] GC(20) Garbage Collection (Proactive) 222M(11%)->102M(5%) [2024-04-18T04:36:19.667+0000][69][gc] GC(21) Garbage Collection (Proactive) 224M(11%)->106M(5%) [2024-04-18T04:41:19.759+0000][69][gc] GC(22) Garbage Collection (Proactive) 226M(11%)->110M(5%)

Describe the bug
版本: BifroMQ 3.0
测试工具: MQTTX

将clean session设置为false,只能收到设备离线期间发送的最后一条消息,且这条消息是qos=0的保留消息,

步骤:
下列链接见Clean Session
https://www.emqx.com/zh/blog/the-easiest-guide-to-getting-started-with-mqtt

但是将服务器地址替换成broker.emqx.io却能准确的收到消息, 请问clean session功能是否默认做保留消息实现? 是否有计划完整实现此功能

To Reproduce
1,创建一个名为 MQTT V3 的连接，设置 Clean Session 为 false，选择 MQTT 版本为 3.1.1。

2,连接成功后，订阅 clean_session_false 主题，并将 QoS 设置为 1。

3,订阅成功后，点击右上角的断开按钮，断开连接。

4,创建一个名为 MQTT_V3_Publish 的连接，MQTT 版本也设置为 3.1.1。连接成功后，向 clean_session_false 主题发布三条消息。

5,接着，选择 MQTT_V3 连接，点击连接按钮重新连接到服务器，只收到最后发送的那条消息 ,且这条消息显示的是qos=0的遗嘱消息

Expected behavior
无

Logs
无

HOST

• CPU: 双核
• Memory: 4G

OS(please complete the following information):

• OS: [e.g. CentOS 8]
• Kernel Version [e.g. 5.6]
  • Kernel Specific Settings: [e.g. TCP, FD, etc]

JVM:

• Version: 17.0.10
• Arguments: 无

BifroMQ

• Version: 3.0
• Non-Default Configuration:

Additional context
无

⚠️ Please ensure that the provided information is as detailed and clear as possible. Lack of information may delay the resolution of the issue.

Describe the bug
cpu很高，客户端pub消息发不出去
看了都是topic-matcher的线程占用高

堆栈信息

BifroMQ

• Version: 3.0.2
• Deployment: Standalone