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.