new to FlashMQ but having problems with a lot of QoS/retained messages being dropped

[simonclayton]

Our use case may not be good for mqtt - I'm not really sure we are quite a long way into using it with mosquitto but FlashMQ outperforms that easily when publishing a large amount of topics/payloads.

In our use case - we have a top level topic that a small number of clients connect to (often 10 always less than 50). During the development phase we're using MQTT Explorer as the tree view is particularly well suited to our use. We have a limited tree but with a lot of topics inside some topics so 12345/data/tablename1/# might then have 50k+ "records" in different payloads inside that topic and there will be multiple tablenameX topics so we could be talking about 250k payloads for a top level topic worst case scenario. These are QoS=1 and retain=1. We are connecting clean every time (we don't seem to be able to do anything else currently).

When I connect to FlashMQ with MQTT Explorer I don't get anywhere near the right number of topics/payloads and the amount I do get varies hugely. In the log I see a lot of messages referencing max_qos_msg_pending_per_client which I have increased to 200k/1073741824 but we still can't get the right data sent on connection. We have more sucess with node.js so I'm assuming that MQTT Explorer just isn't good enough at acknowledging the data but is there anything else we can do to ensure we can get the data?

Thanks in advance

[halfgaar]

Hi Simon,

You're touching upon a shortcoming of MQTT, and how QoS often is misunderstood. What you have to realize, is that the QoS transaction is between client and server. It's not between publisher and subscriber(s). So, it won't help you increase the deliverability to subscribers. In fact, it may make it worse.

Imagine a server with thousands of active clients and messages. Then some client comes along and subscribes to # with QoS 1. This would be too much traffic for a client to handle, especially when the client's connection is slow, so that amount of packets cannot be delivered. What is the server supposed to do? It can't keep writing them to the client buffer, because that will eventually cause the server to run out of memory. Or, the server could stop sending PUBACK packets to the publishers to slow them down? Obviously not, because that would be too easily exploitable. In practice, what happens is that packets are dropped, whether they are QoS 0, 1 or 2.

So, this means the publishers will all have gotten their PUBACK, so the QoS 1 transmission is complete, but client(s) who are interested may not have received anything.

I have never used Kafka, but it's pull vs push nature may be better suited to your needs. But even then, if the consumers can't consume fast enough, it will still be a problem.

Note that you didn't clarify whether you are talking about on-line delivery, or getting retained delivery upon subscription to topics. I'm not sure if you saw it, but FlashMQ recently got an update that improves the latter. It will allow a client to receive dozens of millions of retained messages reliably, although not always in the same order.

For on-line delivery; if you need something that slows down your publishers so your subscribers have time to consume, maybe the only option would be to implement something on top of the MQTT transport that allows your clients to communicate with each-other and establish some kind of flow control or way to request topics.