Hello Flespi Team,
The metrics displayed for an MQTT session include a size and a count, just wanted to understand how they are related.
For example, in the below screenshot, the size for "Volume of messages published with QoS > 0 and waiting for PUBACK from client side" is 0B, but the count says 1999.

  1. Does this mean there are 1999 messages currently waiting PUBACK from client size?
  2. Why is the size 0B, even though there are 1999 messages?
  3. How are these metrics ("Last session outbound traffic volume" and "Volume of messages published with QoS > 0 and waiting for PUBACK from client side") related to the total storage size of the session?
  4. The total storage size of the session in the screenshot is 144.64MB, which is more than the size of two metrics combined. What else is contributing to the total size of the session?
  5. If the total storage size of the session is from "Volume of messages published with QoS > 0 and waiting for PUBACK from client side", is there an API endpoint we can use to retrieve them?
  6. If the total storage size of the session is not related to the two metrics above, what else is contributing to the size and what can we do to clear/reduce the session storage once it hits the limit?

Thanks!

    Sorry for misleading information. These metrics should be splitted into two separate once.

    First (0B) - is a volume of messages with QoS>0 waiting for a publishing.
    Second (1999) - is a number of messages in queue waiting for PUBACK from client side.
    Storage - is a persistent session storage size.

    We will fix it in nearest future.

      dexif Thanks for the clarifications.
      Sorry if these are newbie questions.
      We have an MQTT client connected to the session with a large number of messages in queue waiting for PUBACK from client side. We don't see any of these messages being retransmitted by the Flespi broker.
      Is there any way to force the broker to retransmit the QoS 1 messages waiting for PUBACK?

      Is there any way to retrieve these QoS 1 messages waiting for PUBACK from the broker using an API or something?

      Regarding the persistent storage:
      What else (in addition to the QoS 1 messages waiting for PUBACK from the broker) is causing the persistent storage to go up?
      I noticed that some of the sessions with less messages in PUBACK queue have higher persistent storage compared to sessions with high messages in PUBACK queue. So I think persistent storage is not not proportional to the message in PUBACK queue.

      We are reconnecting to the same session and actively receiving messages from that session, but that doesn't clear the persistent storage.
      What else can we do to clear/reduce the persistent session storage once it hits the limit?
      Thanks again for all the help so far.

          4 days later

          • shal

          • Post #4
          • Edited

          muneeb It's hard to assist you here. The most obvious reason of the problem is the processing of MQTT message on your side or network connection I/O processing by the mqtt client library.

          So the very first question will be - what library are you using?

          Next thing to do is to eliminate library error from user-level error.
          First create empty handler for the message and check if such kind of client connections are OK. If not - you have an error with library.

          If you were OK on previous stage, create a handler with 0.1-1 second sleep - if your code is synchronous - the delay should be quite small to be able for the code to handle all messages. And check how it is going. If you have problems - either delay is too large or the processing of network I/O in your library is not good.

          In al other cases the problem will lay to your original handler - e.g. your message processing code.

          Just to ensure that broker operates good - create a few sessions using https://mqttboard.flespi.io - their handler will just output message into browser. If for any reason you have problems there - please immediately contact flespi team via chat button in top-right corner of your flespi.io. Sometimes we discover gnomes in datacenter between racks and they do some magic things. Hope it is not your case.

          And yes - for most of your questions above the answer is NO. This is just simple MQTT Broker, nothing more. By the protocol there is no retransmit packet command - client should just close the connection if anything went wrong.

            Write a Reply...