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

Synchronization error on noBufferedMessages #1494

Open
fpagliughi opened this issue Jun 17, 2024 · 1 comment
Open

Synchronization error on noBufferedMessages #1494

fpagliughi opened this issue Jun 17, 2024 · 1 comment
Milestone

Comments

@fpagliughi
Copy link
Contributor

Got a bug report from @elzbieta-nowak-kubat on the Paho C++ repo where publishing from two threads cause the application to hang:

I have investigated it a bit and it seems that the problem is caused by wrong synchronization of noBufferedMessages member of MQTTAsync on pahoc side. In can happen that two threads can simultaneously accesses the check on this member, both commands are added to the list and increase this number, so in effect in MQTTAsync_add function processing enters condition

/* delete oldest message if buffer is full.  We wouldn't be here if delete newest was in operation */
if (command->client->createOptions && (command->client->noBufferedMessages >= command->client->createOptions->maxBufferedMessages))

where it should never enter for our create options (delete_oldest_messages(false)) and then ListDetach is called which causes removing the first publish command from the processing. So on pahocpp side wait corresponding to the publish never gets released.

eclipse-paho/paho.mqtt.cpp#499

@fpagliughi fpagliughi changed the title Synchronizatio error on noBufferedMessages Synchronization error on noBufferedMessages Jun 17, 2024
@icraggs icraggs added this to the 1.3.14 milestone Jul 9, 2024
icraggs added a commit that referenced this issue Sep 3, 2024
icraggs added a commit that referenced this issue Sep 3, 2024
@icraggs
Copy link
Contributor

icraggs commented Sep 4, 2024

I don't think it was exactly at the place pinpointed, but a similar scenario. I would say that setting the maximum no of buffered messages to 1 isn't useful, but serves in this case to highlight an issue.

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

No branches or pull requests

2 participants