I’m getting a timeout error when I publish a topic using PublishAsync, in the HIVEMQ MQTT C# Client. Our project requires that the message be sent with a QoS value of 1. The subscriber has subscribed using a wildcard. Here is the publish topic: “/top/vc/set_position”. The subscriber is subscribing to “/top/vc/#”.
I’m able to publish another message that is sent without error using PublishAsync and received by the subscriber earlier in the code. This message is published before the message that is having the error. The message is sent with a QoS of 2. The topic that is being published is “/top/vc/initialize”. As shown above the subscriber has subscribed to “/top/vc/#”.
Is this a subscription issue or something else?
Hello @dougscg ,
Thank you for the interest in MQTT, and welcome to the HiveMQ Community!
Based on the details provided, it sounds like we may be seeing some trouble with the client completing its QoS-dictated validation. With that in mind, I’d like to ask if you are able to share the client code that is sending these messages so we can review further - specifically, the PublishAsync block, obfuscating anything that is privileged data such as usernames, passwords, domains, etc. Additionally, if you could provide the broker implementation, whether this is using a public broker, a HiveMQ Cloud Broker, a local installation, or other configuration, that would be helpful as well.
I’d also like to ask you to disconnect this client, reconnect, and then attempt sending only QoS 1 messages to check for proper message flow.
Let us know if you are able to share these details, and welcome again to the HiveMQ Community!
Best,
Aaron from the HiveMQ Team
Thank you for your response, Aaron. I will work on getting the code blocks you requested. I will post that shortly.
I did do a change in my code to set all QoS values to 0 in all published messages and after doing that the app was able to publish and receive all messages in the system. Moving forward with that for the time being so we can get the logic flushed out for the application.
We are using a HiveMQ Cloud Broker.
Here is the publish code block: [using protobuf for message payload definitions]
Ship.Container.SelectWidgetRequest selectedWidget = new()
{
Id = "This is a test"
};
MQTT5PublishMessage selectWidgetMsg = new()
{
Topic = "ship/container/widget_selected",
Payload = selectedWidget.ToByteArray(),
QoS = QualityOfService.AtLeastOnceDelivery,
ResponseTopic = "ship/response/container/widget_selected"
};
try
{
await _client.PublishAsync(selectWidgetMsg).ConfigureAwait(false);
}
catch (Exception e)
{
_logger.LogError("Widget Selected Request failed. {0}", e.Message);
}
Hello @dougscg ,
Thank you for the additional details!
We are performing some additional investigation, and I wanted to ask if you would be able to perform a test with the current client configuration. I’d like to see if it would be possible to publish a QoS 0, 1, and then 2 message and verify receipt by the subscribing client, and then attempt the inverse - a QoS 2, 1, and then 0 message to verify receipt by the subscribing client.
To confirm, has QoS 0 continued to transit messages without issue, as well?
Best,
Aaron from the HiveMQ Team
Aaron,
Yes, I should be able to do the tests that you requested. I will post the results later today.
Yes, with QoS 0 messages are transmitted without issue.
Doug
OK, I ran the tests as you requested and here’s the results:
QoS 0 => all messages sent and received
QoS 1 => all messages sent and received
QoS 2 => some messages send and some generate time out errors
The reverse order did the same.
Hello @dougscg ,
Thank you for the follow-up!
In order to review this further, we are looking to perform some internal replication testing.
In the interim, could I have you confirm that, after sending QoS 2 messages and receiving intermittent success, QoS 1 and 0 messages were able to send successfully within the same client session?
Best,
Aaron from the HiveMQ Team
Aaron,
I cannot confirm that status. When I ran my tests, each was it’s own session, since I would have to halt the application, modify the code and then execute the app again. I will try to rework the test to do what you were inquiring about and let you know the results. It will be sometime next week before I could attempt that.
Regards,
Doug