Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After putting on significant Load with using paho mqtt package, i could see that few of my client not receiving msg.payload even though the message is being published as Expected. #460

Closed
RabiyaBasriShaik opened this issue Oct 30, 2020 · 4 comments

Comments

@RabiyaBasriShaik
Copy link

the code which is being used for the services are as belows.

   	var subCb mqtt.MessageHandler = func(cli mqtt.Client, message mqtt.Message) {
	topic := message.Topic()
            recvdPayload := message.Payload()
    }
    var cliOpts *mqtt.ClientOptions
cliOpts = mqtt.NewClientOptions()
uid := guuid.New()
clientId := uid.String()
cliOpts.AddBroker(*broker)
cliOpts.SetUsername(*Id)
cliOpts.SetPassword(*Tok)
cliOpts.SetClientID(clientId[:20])
cliOpts.SetOrderMatters(false)
cliOpts.SetCleanSession(false)
cliOpts.SetDefaultPublishHandler(subCb)
cliOpts.SetConnectionLostHandler(connLostHandler)
cliOpts.SetOnConnectHandler(onConnected)
cliOpts.SetConnectTimeout(10 * time.Second)
client := mqtt.NewClient(cliOpts)

defer func() {
	fmt.Println("Sub disconnect:", id)
	client.Disconnect(4000)
}()

for true {
tok := client.Connect()
tok.Wait()
if tok.Error() != nil {
	fmt.Println("Connect failed..")

} else {
	fmt.Println("Connect success..")

}

tok = client.Subscribe(*topic, 1, subCb)
tok.Wait()
if tok.Error() != nil {
	fmt.Println("Subscribe failed..")
	fmt.Println(tok.Error())
} else {
	fmt.Println("Subscribe success..")
}
@MattBrittan
Copy link
Contributor

MattBrittan commented Oct 30, 2020

Sorry - we would need significantly more information in order to be able to assist.

I am unclear as to what "not receiving msg.payload" means; do you mean that you are receiving the message but the payload is not as expected or is it just that some messages are being lost? If it's lost messages then see this issue for one potential cause (cause was broker configuration) and information as to how the issue was traced.

For this kind of issue a Minimal, Reproducible Example is a requirement (otherwise we are left guessing as to potential causes; many of which are unrelated to this package). The simplest way of providing this is to use docker with three containers (publisher, broker, subscriber) and I'm happy to provide you with a base setup if you would like to adopt that approach (edit: This is now available under cmd/docker)

While the logs (see my response on this issue for instructions on enabling logging - edit: now in the readme.md) can be useful you would first need to establish where the issue is (the problem could be with the publisher, broker or subscriber). Hopefully my comments in the issue linked above provide some pointers as to how to best narrow down the issue.

@RabiyaBasriShaik
Copy link
Author

@MattBrittan , Please find below more details about the issue I am facing .

I am using Paho mqtt library to publish and subscribe messages in golang, am using MQTT broker . I have added print statements to verify that publishing and receiving of messages is happening successfully.

My publish subscribe code is working absolutely fine, if am publishing 1000 messages for 500 clients. In this case, I could see that 3 or 4 messages were not received at the client. That was negligible issue.
However, if I start increasing number of clients gradually , till 5000, and then publish 50000 messages; nearly 15000 messages were lost at the client side.

Few of the clients are not able to receive message even though publish is happening successfully. Consequently, I am not able to extract payload from the message ( which is supposed to be received , but its lost )
To put it another way, the receiving of message is not consistent among clients upon increasing number of clients and number of messages published .

Could you suggest any workaround to make all clients receive the messages .

@MattBrittan
Copy link
Contributor

MattBrittan commented Nov 2, 2020

@RabiyaBasriShaik thanks but unfortunately the information you provided is not detailed enough. As per my last comment a Minimal, Reproducible Example is the best way to provide the level of information needed to assist you. Without this anything I say is a guess (I don't know the basics; what broker are you using, what QOS level the message is published with, what version of the library you are using etc) and cannot know if the issue is even related to this library. Please see the readme.md, which I updated over the weekend, for more information on the data you will need to provide (and other resources).

Having said that it is important that you understand that communication via MQTT works in stages. So your publisher sends a message to the broker; once the broker has the message and acknowledged it the publisher plays no further role (there is no end-to-end acknowledgement). The broker will then attempt to deliver the message to the subscribers. As such if any of your subscribers are receiving the message then the issue is not related to the publisher (other than, possibly, the use of QOS0). I pointed you towards another issue that appears to match your symptoms; have you taken a look at that?

Also re "In this case, I could see that 3 or 4 messages were not received at the client"; at QOS1+ you should not loose any messages. If you are then there is a problem (as per the above I cannot tell you where this is without a lot more information).

@MattBrittan
Copy link
Contributor

I'm closing this issue due to inactivity and a lack of information which would enable us to locate the issue (or confirm if it is in this package or elsewhere). If you are still experiencing the issue please upgrade to version 1.3.0 and see if that resolves it. If not feel free to reopen this issue but we will require additional information - unfortunately these issues can be difficult to trace and, as per the issue I referred you to, can be caused by other factors such as the Broker configuration. This means that its not really possible to do much unless we can replicate the issue or you provide logs that enable us to see what is going wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants