I have an intermittent problem with my Python client implementation, and I'm looking for some help.
I am trying to create a minimal test case, but the problem seems to be dependent on timing, which suggests a race condition.
My code looks like this (simplified):
...
client = mqtt.Client(client_id=self.ecn, clean_session=False, userdata=None, protocol=mqtt.MQTTv311, transport="tcp")
...
(configure callbacks etc.)
...
client.connect(host, int(port), keepalive=60)
client.loop_start()
self.ms_client = client
...
message_info = self.ms_client.publish(topic, payload=json.dumps(payload), qos=2, retain=False)
message_info.wait_for_publish()
The problem is that wait_for_publish() never returns.
If I remove it, then everything works fine, and my on_publish() callback is called as expected.
But I want to handle each publish synchronously.
I tried replacing wait_for_publish() with is_published() as follows:
while not message_info.is_published():
time.sleep(1)
But the result is the same. The code just hangs.
What is interesting is that if I replace time.sleep() with a call to loop():
while not message_info.is_published():
self.ms_client.loop(1)
This works!
Does this suggest a deadlock in the threaded interface?
I have looked through the GitHub issues, and
#309 sounded somewhat related.
But this was fixed in 1.4, and I have tested both 1.3 and 1.4 and both display the problem.
Steve Cope's
website mentions some "strange behaviour" when using loop_start().
Does this suggest there may be a race condition in the threaded interface?
Any other suggestions appreciated,
Ben.
