-
Notifications
You must be signed in to change notification settings - Fork 49
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
[BUG] when call MQTTAgent_Publish it is necessary waiting portMAX_DELAY in xTaskNotifyWait ..otherwhise application crash. Why? #112
Comments
Thanks for reporting, I'll have the team to review your findings and get back to you. |
The reason for the crash you observe is -
If the function prvPublishToTopic, returns before the PUBACK is received, this |
The option is to queue messeges to send into a queue and use a different task for publish them. In this way the main task can continue to work. Beside all, the publish is very slow (as already discussed in #44) also for QoS0 when we should expect to be very fast. |
Note that MQTT Agent also has a queue, so this will be 2 level of indirection. Is it possible to have only one task doing all the publishes?
This is something that needs to be investigated. Can you try to put some logs at the following places for QoS0 -
This will help us understand what part is taking more time. |
Hello @aggarg LOGW - "PLACEHOLDER_issues#112_002": When the command is added to the MQTT_Agent's command queue - https://github.com/FreeRTOS/coreMQTT-Agent/blob/main/source/core_mqtt_agent.c#L529. LOGW - "PLACEHOLDER_issues#112_003": When the command is picked up for processing - https://github.com/FreeRTOS/coreMQTT-Agent/blob/main/source/core_mqtt_agent.c#L569. LOGW - "PLACEHOLDER_issues#112_004": When the command execution is complete - https://github.com/FreeRTOS/coreMQTT-Agent/blob/main/source/core_mqtt_agent.c#L802. LOGW - "PLACEHOLDER_issues#112_005": When the command completion callback is called - https://github.com/FreeRTOS/iot-reference-esp32/blob/main/main/demo_tasks/sub_pub_unsub_demo/sub_pub_unsub_demo.c#L336. LOGW - "PLACEHOLDER_issues#112_006":When MQTTAgent_Publish returns - https://github.com/FreeRTOS/iot-reference-esp32/blob/main/main/demo_tasks/sub_pub_unsub_demo/sub_pub_unsub_demo.c#L513.
as far as i can log We start at (29252) and finish at (33472) = taking about 4 seconds
|
I just recompiled the application with only sub_pub_unsub_demo demo. The log is simple to be read: fulllog file: log1
log2
|
Thank you for capturing and sharing these logs. It seems that there are multiple |
Hello @aggarg now running at QoS = 0 #define CONFIG_GRI_SUB_PUB_UNSUB_DEMO_QOS_LEVEL 0 ad double check this is a LOG with QoS = 0
|
just checking with QoS= 0 --> 44836 - 40836 = 4000 msec again
|
the time lost seem in the double loop into 4 -> 3 (+2000 msec)
and also from 2 -> 3 (+2000 msec)
|
Did you change this flags manually? I think you are supposed to use Can you try to increase the MQTT Agent task's priority? |
i used menuconfig (project is in espress-ide ) I (38776) sub_pub_unsub_demo: Subscribe 7 for topic filter /filter/SubPub0 succeeded for task "SubPub0".
Also changed the CONFIG_GRI_MQTT_AGENT_TASK_PRIORITY to 6 (using menuconfig) but the result seem the same I (11886) sub_pub_unsub_demo: Unsubscribe 3 for topic filter /filter/SubPub0 succeeded for task "SubPub0". |
hello @aggarg so changing recvTimeoutMs in timeouts of
now the Publish take 500 to 1000 msec instead of 4000 msec so it seem something related to the network_transport.c recvTimeoutMs value.
here the log
|
Thank you for diving deep and finding that!
This should be fine and this PR seems to be doing that - #104. Does this PR solve your issue? |
Hello. Confirmed PR #104 resolve the issue. |
Hello. Confirmed PR #104 resolve the issue. |
Thank you for doing all the debugging! |
Describe the bug
during MQTTAgent_Publish, can happen that mqtt connection goes down (wifi is connected) and happen that the task calling the MQTTAgent_Publish is blocked waiting the Publish notification in xTaskNotifyWait( 0, 0, &ulNotification, portMAX_DELAY ).
if this xTaskNotifyWait is changed ot some timeout like xTaskNotifyWait( 0, 0, &ulNotification, pdMS_TO_TICKS(2000) );
I faced that the MQTTAgent_Publish fastly cause a crash as we can see in the screenshot .
who can avoid to wait portMAX_DELAY that block my task?
System information
"Code to reproduce bug"
.Expected behavior
i'm expecting that the MQTTAgent_Publish exit for some timeout always.
presently i can set only a timeout: xCommandParams.blockTimeMs = waitTimeoutMsec; that seem to be not working if the publish is already queues.
if i try to avoid the notification xTaskNotifyWait( 0, 0, &ulNotification, portMAX_DELAY ) by commenting the line
the application fastly going in crash
there is a way to allow the Publish wait for a timeout only without crashing?
Screenshots or console output
If appropriate, please paste the console output/error log explaining the issue. If possible, include the call stack.
Steps to reproduce bug
Example:
1. "I am using project [ ... ], and have configured with [ ... ]"
2. "When run on [ ... ], I observed that [ ... ]"
Code to reproduce bug
// xCommandParams.cmdCompleteCallback = prvPublishCommandCallback;
Additional context
Include any additional context relevant to the issue here.
The text was updated successfully, but these errors were encountered: