We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
请教一下, 以下是我debug过程中的分析, 请指正是否正确? ConnectProcessor processRequest(ChannelHandlerContext ctx, MqttMessage mqttMessage) 中保存will message 到 willMessageStore,但是没有地方保存在will topic 到subscriptionMatcher中。 所以在发送will message 的时候, subscriptionMatcher match 不到对应的will topic的Subscription。从而导致will message 发送不成功 Set subscriptions = subscriptionMatcher.match((String) message.getHeader(MessageHeader.TOPIC));
The text was updated successfully, but these errors were encountered:
Hi,你分析的内容是正确的,但是WillMessage并不是这样使用的,而且并不是“发送不成功”,而是“发送了没有客户端订阅”。
WillMessage在MQTT协议中的作用是:当出现网络问题(心跳丢失等等4个条件,参考官方MQTT协议PDF)的时候,客户端无法正常发送DISCONNECT报文,就掉线了。这个时候如果客户端在CONNECT阶段设置了WillMessage,Broker会将它发送出去。
举个具体的应用例子:业务协议约定,WillMessage的主题为/will/{clientId},内容为:{'status':'offline'},这样,当设备异常掉线(比如拔掉网线导致心跳丢失),设备端断网了没有能力告知服务端自己已经掉线了,但是没关系,Broker会将这条WillMessage消息发送出去,此时如果后端有业务服务正在监听"/will/#",那么就可以收到这条消息,就知道设备掉线了,而且是异常掉线的。
Sorry, something went wrong.
一种预设的异常处理机制?跟**重发标志(DUP)**是不一样的,我还一直以为是dup的实现。
No branches or pull requests
请教一下, 以下是我debug过程中的分析, 请指正是否正确?
ConnectProcessor processRequest(ChannelHandlerContext ctx, MqttMessage mqttMessage) 中保存will message 到 willMessageStore,但是没有地方保存在will topic 到subscriptionMatcher中。 所以在发送will message 的时候, subscriptionMatcher match 不到对应的will topic的Subscription。从而导致will message 发送不成功
Set subscriptions = subscriptionMatcher.match((String) message.getHeader(MessageHeader.TOPIC));
The text was updated successfully, but these errors were encountered: