Please fill out the form below before submitting, thank you!
[x ] Bug exists Release Version 1.2.5 ( Master Branch)
[ ] Bug exists in MQTTv3 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
[ ] Bug exists in MQTTv5 Client on Snapshot Version 1.2.6-SNAPSHOT (Develop Branch)
Hello,
I am trying to develop my own SDK doing something customized by using paho sdk. My receiver client interaction with MQTT broker goes :
receiving messages (requests) from senders
reply to the messages (requests) to the senders
However, in concurrent scenario, i.e. multiple requests and replies, the receiver client may fail to reply by calling MqttAsyncClient.publish(String topic, MqttMessage message).waitForCompletion(timeout) , even though the timeout value here is large.
I captured the packets by using Wireshark and found that there is a piece of information of TCP zero window when the above invocation was failed.
I dump the threads when the case occurred:
`"MQTT Rec: responder" #21 prio=5 os_prio=31 cpu=61.34ms elapsed=59.63s tid=0x00007fabf60ca000 nid=0x7903 in Object.wait() [0x000070000db2b000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.11/Native Method)
waiting on
at org.eclipse.paho.client.mqttv3.internal.CommsCallback.messageArrived(CommsCallback.java:364)
waiting to re-lock in wait() <0x000000078452b3a0> (a java.lang.Object)
at org.eclipse.paho.client.mqttv3.internal.ClientState.notifyReceivedMsg(ClientState.java:1096)
at org.eclipse.paho.client.mqttv3.internal.CommsReceiver.run(CommsReceiver.java:167)
at java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.11/Executors.java:515)
at java.util.concurrent.FutureTask.run(java.base@11.0.11/FutureTask.java:264)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(java.base@11.0.11/ScheduledThreadPoolExecutor.java:304)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.11/Thread.java:834)
`
`"MQTT Call: responder" #23 prio=5 os_prio=31 cpu=78.47ms elapsed=59.42s tid=0x00007fabf68b4000 nid=0x7e03 in Object.wait() [0x000070000dd30000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.11/Native Method)
waiting on
at org.eclipse.paho.client.mqttv3.internal.Token.waitForResponse(Token.java:145)
waiting to re-lock in wait() <0x0000000786eae688> (a java.lang.Object)
at org.eclipse.paho.client.mqttv3.internal.Token.waitForCompletion(Token.java:108)
at org.eclipse.paho.client.mqttv3.MqttToken.waitForCompletion(MqttToken.java:67)
`
I think the receding thread was in the loop infinitely and cannot not exit, thus causes the TCP window never increases and the receiver client cannot receive any data after data.
Please fill out the form below before submitting, thank you!
Hello,
I am trying to develop my own SDK doing something customized by using paho sdk. My receiver client interaction with MQTT broker goes :
However, in concurrent scenario, i.e. multiple requests and replies, the receiver client may fail to reply by calling
MqttAsyncClient.publish(String topic, MqttMessage message).waitForCompletion(timeout), even though thetimeoutvalue here is large.I captured the packets by using
Wiresharkand found that there is a piece of information ofTCP zero windowwhen the above invocation was failed.I dump the threads when the case occurred:
`"MQTT Rec: responder" #21 prio=5 os_prio=31 cpu=61.34ms elapsed=59.63s tid=0x00007fabf60ca000 nid=0x7903 in Object.wait() [0x000070000db2b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(java.base@11.0.11/Native Method)
`"MQTT Call: responder" #23 prio=5 os_prio=31 cpu=78.47ms elapsed=59.42s tid=0x00007fabf68b4000 nid=0x7e03 in Object.wait() [0x000070000dd30000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(java.base@11.0.11/Native Method)
I think the receding thread was in the loop infinitely and cannot not exit, thus causes the TCP window never increases and the receiver client cannot receive any data after data.
Thanks for your work and for your consideration.