Subscription timeout issue

Mosquitto MQTT Broker
1

Hello everyone!

I occasionally experience a 30-second subscription timeout issue when using the mosquitto broker. I have checked the logs and there doesn’t seem to be any disconnection. What could be causing this issue?

2

Hi susukuyu,

Can you be a bit more specific? :slight_smile:
How do you know it is 30 seconds.

In the logs you will see something! If a client tries a connection, the broker will log this. Does not matter, if the connection is successful or not.

You can enable further logging via log_type all as a configuration setting.
If possible add these to the forum :slight_smile:

3

Hi, Tizian.

Thank you for your response.

I found that the 30-second timeout occurred in the part where I receive fixed messages. The timeout time was set by me.

The log recorded that other clients disconnected.

These clients were communicating with each other before the problem occurred. I’m not sure if there is any connection between them?

Here is the log：
2023-10-15T09:09:24: Client {f508dc6d-8098-40ce-917e-49c0f034f494} has exceeded timeout, disconnecting.
2023-10-15T09:10:00: Outgoing messages are being dropped for client {c8aef310-52b9-4f83-a5bd-da8758eef193}.
2023-10-15T09:10:00: Outgoing messages are being dropped for client {d7503df7-7380-4718-844e-bc3b00f3f219}.
2023-10-15T09:10:00: Outgoing messages are being dropped for client {02363cbd-7ad1-4568-8cef-51b52ab245ff}.
2023-10-15T09:10:00: Outgoing messages are being dropped for client {0e1ad1b5-ce09-4217-9de2-1c60ed46f45d}.
2023-10-15T09:10:01: Outgoing messages are being dropped for client {7d63529f-cab0-4d45-8cfe-b14a3eeb5d2e}.
2023-10-15T09:10:01: Outgoing messages are being dropped for client {10c4e8c6-755f-47d6-bb39-94fc95bc4495}.
2023-10-15T09:10:06: New connection from 127.0.0.1:50282 on port 1883.
2023-10-15T09:10:06: New client connected from 127.0.0.1:50282 as {f508dc6d-8098-40ce-917e-49c0f034f494} (p1, c0, k300).
2023-10-15T09:10:06: {f508dc6d-8098-40ce-917e-49c0f034f494} 0 SurvivalCheck
2023-10-15T11:50:01: Client {402ad827-e8ef-44ef-b069-fe66285c0ebb} closed its connection.
2023-10-15T11:50:01: Client {cdceee88-9c38-4f33-a656-56a3228671e7} closed its connection.
2023-10-15T11:50:01: Client {7d63529f-cab0-4d45-8cfe-b14a3eeb5d2e} closed its connection.
2023-10-15T11:50:02: Client {cf19661b-57dd-48fc-a037-7f93e825582a} closed its connection.
2023-10-15T11:50:02: Client {63ec00f0-80ca-443b-93b5-e12955f0ef0c} closed its connection.
2023-10-15T11:50:02: Client {10c4e8c6-755f-47d6-bb39-94fc95bc4495} closed its connection.
2023-10-15T11:50:02: Client {f54f6169-9b1a-4f37-9e3e-8c23faaace43} closed its connection.
2023-10-15T11:50:02: Client {0e1ad1b5-ce09-4217-9de2-1c60ed46f45d} closed its connection.
…

4

Hi ,

Outgoing messages are being dropped for client can be an indicator for the queue size being fully used.
The queue is used for QoS messages and sets a limit for messages being processed by the broker.
The reason for this could be that either the broker is under high load for some time, or maybe clients misbehave. Could that be a reason?

max_queued_messages 1000

This option sets the maximum number of heap memory bytes that the broker will
allocate, and hence sets a hard limit on memory use by the broker. Memory
requests that exceed this value will be denied. The effect will vary
depending on what has been denied. If an incoming message is being processed,
then the message will be dropped and the publishing client will be
disconnected. If an outgoing message is being sent, then the individual
message will be dropped and the receiving client will be disconnected.
Defaults to no limit.

5

Hi,

The “max_queued_messages 1000” is set to its default value.

If the broker is overloaded, will it reject messages (including heartbeat messages) and disconnect the connections of publishing and subscribing clients after 1.5 heartbeat times?

Because I have deployed the broker on a low-end computer, I suspect the issue is caused by high broker load. Therefore, I would like to know what measures are taken if the broker is overloaded.

6

Hi,

I found that the reason was due to the high load on the broker, but I am not sure why the broker was overloaded because another machine in the same environment has not appeared before. How should I prevent it?

7

I am not sure, what exactly this means. Can you clarify a bit, please?

8

Some computers are experiencing high broker loads while others are not, even though their operating environments are the same. Can I prevent this situation by adjusting settings?
Sorry, English is not my native language, and the above statements are translated by software. It may cause ambiguity.

9

Hello,

Don´t worry we will handle it :slight_smile:

I think how you can understand more about the differences of your setups could be to monitor them.
You can combine monitoring of the used hardware resources and enable log_type all in your configuration file.

This way you can learn more about what is happening on the broker to a given time.
There you can also spot differences in behavior.

If you are experiencing high loads and want to prevent this, you have to understand the reason for the overload first. Depending on this, you can identify the solution. But without the reason, there is not yet much you can do.

10

Hi,

Thank you very much for your answer. This question has been bothering me for a long time :sweat_smile:.

I opened the debugging log and found that the 30s subscription timeout was due to the broker not sending me a heartbeat until the next 30s. Is this caused by overloaded broker?