Backpressure support

HiveMQ Client Library
1

Hi,

I am doing a bachelor thesis about the performance of MQTT under backpressure, where I want to compare a reactive and an imperative approach. I have therefore looked at HiveMQ, because it supports backpressure, and it has a blocking and a reactive API flavour which I am considering to test. I have played a little with HiveMQ, and have got the community edition broker talking with the blocking clients locally. I have some questions though which I hope you can help me with:

  1. Is backpressure implemented in all of the flavours, or only in the reactive version?
  2. Should any additional thing be done to invoke backpressure, or is following the readme enough?
  3. Can you point me somewhere where I can read about HiveMQ’s backpressure support, or can you send me something (examples/documentation)?

I would appreciate your help :slight_smile:

Best regards,
Mustafa

2

Hi Mustafa,

It’s awesome to see you have chosen the topics of MQTT and backpressure for your bachelors thesis!
Please do keep us updated :slight_smile:

Regarding your querries:

  1. With the reactive API you can implement non-blocking backpressure in both directions (sending and receiving messages). When using the asynchronous or blocking APIs, method calls for sending messages will block when backpressure is applied by the broker. With the asynchronous API backpressure for receiving messages can not be applied without blocking in the callback (which is not a good idea). With the blocking API backpressure is applied to the broker if the receive methods are not called.

  2. Please read about reactive pull backpressure of the reactive-streams specificationand flow control of the MQTT 5 specification

  3. HiveMQ limits the amount of inflight messages via send and receive maximum. You can configure these at the broker and the client. Please also read about flow control of the MQTT 5 specification.

Let us know, if we can provide further assistance.

Kind regards,
Florian

3

Hi @hivemq-support,

Thanks for your reply and the references, I have been studying them today :slight_smile:

I have also been working further with the clients and the broker, and yes I have further questions on how to enable backpressure which I hope you can help me with. I understand that to enable backpressure I need to change the receive maximum, which I am trying to do by following this example where the restrictions and the receivemaximum is set: https://github.com/hivemq/hivemq-mqtt-client/blob/82e3512dc1a3f1ecd08793de89f8a2835a10e455/examples/src/main/java/com/hivemq/client/mqtt/examples/Mqtt5Features.java

But when I then test it, the rate at which the data is transfered is not changed, as if my change doesn’t have any effect, regardless of how low I set it. But if I change the maximumPacketSize, then I observe that the subscriber doesn’t receive packets that exceeds the limit maximumPacketSize. So maximumPacketSize works, but I can’t get the backpressure to work.

So to put it into code, this how the subscriber connects:
client.connectWith()
.restrictions()
.receiveMaximum(5)
.applyRestrictions()
.send()

And this is how the publisher connects:
client.connectWith()
.restrictions()
.sendMaximum(5)
.applyRestrictions()
.send();

But this doesn’t seem to work. Am I missing something?

4

Another thing I experience is that when I print the MQTTConnAck message which I receive from the broker, it displays the following:

image
image1586Ă—29 7.23 KB

receivemaximum is always 10, regardless of what I change it to, and it’s 10 also in the case where I don’t even change it, but when I look at the broker code, it should default it to 65,535 when not changed, so not sure why I get 10 in the MQTTConnAck message.

5

Hello @mura1601

as @hivemq-support said there are two different “receive maximum”. The one in the CONNECT packet (set by the client) tells the broker how many Qos > 0 messages the client is willing to process concurrently and the other in the CONNACK packet (set by the broker) tells the client how many Qos > 0 messages from that client the broker is willing to process concurrently. The latter can be configured via the config.xml

So looking at the CONNACK only gives you the information how the broker set the receive maximum between him and the client (where 10 is the default).

Can you share how you test the backpressure so that we can figure the problem out together? Maybe you are using Qos 0 for example?

Kind regards,
Michael

2 Likes