Crash after second request to not accessible target

[andrewk123]

I have an ESP8266 IOT sending "push messages" to a NodeJS server. All works fine as long as the server is available and responds to the requests.

If however the server is not available then I get the following behavior.

• IOT sends first request after initialization : http.readyState() before sending is 0. A callback with a response code of -4 is generated after approx. 30 secs. Setting http.setTimeout to a large (60) or small (1) value has no impact on this timeout.
• If you wait until the first request "times out" before the IOT sends its second request then you get a http.readyState() before sending of 4 and when the second packet times out with a response code of -4 all is good
• If you wait until the second request "times out" before the IOT sends its third request then you get a http.readyState() before sending of 4 and when the third request times out with a response code of -4 all is good
• If however the IOT sends its third request before receiving the -4 response code (associated with the second request) the http.readyState() before sending is 0. When the second request times out with a response code of -4 all is good. However when the third request times out the ESP restarts immediately.

If I modify my code to only send on a http.readyState() of 4 after the first request is sent (after initialization the http.readyState() is always 0) then the crashes are avoided.

Questions:

1. Is it possible to decrease the "-4" timeout when the remote device is not available.
2. Is there any way to avoid the crash other than by only sending requests (after the initial one) when the http.readyState() is 4?

Thanks for your help with this one.

[boblemaire]

Can you set debug true and run that sequence to the crash, then post the complete debug output?

On Oct 19, 2021, at 9:34 AM, andrewk123 @.***> wrote:

 I have an ESP8266 IOT sending "push messages" to a NodeJS server. All works fine as long as the server is available and responds to the requests.

If however the server is not available then I get the following behavior.

IOT sends first request after initialization : http.readyState() before sending is 0. A callback with a response code of -4 is generated after approx. 30 secs. Setting http.setTimeout to a large (60) or small (1) value has no impact on this timeout. If you wait until the first request "times out" before the IOT sends its second request then you get a http.readyState() before sending of 4 and when the second packet times out with a response code of -4 all is good If you wait until the second request "times out" before the IOT sends its third request then you get a http.readyState() before sending of 4 and when the third request times out with a response code of -4 all is good If however the IOT sends its third request before receiving the -4 response code (associated with the second request) the http.readyState() before sending is 0. When the second request times out with a response code of -4 all is good. However when the third request times out the ESP restarts immediately. If I modify my code to only send on a http.readyState() of 4 after the first request is sent (after initialization the http.readyState() is always 0) then the crashes are avoided.

Questions:

Is it possible to decrease the "-4" timeout when the remote device is not available. Is there any way to avoid the crash other than by only sending requests (after the initial one) when the http.readyState() is 4? Thanks for your help with this one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[andrewk123]

Here you go... I've left some of my debug messages in there which you (hopefully) will be able to match to the scenario above.

Note that the "crash" occurs right at the time that the response from the third request (the one launched with a http.readyState() of 0) would be expected to arrive.

[6709] Ready State: 0 [6709] Push Sent Debug(6710): setDebug(on) version 1.1.15 Debug(6710): open(GET, http://192.168.59.184:2002/?valu) Debug( 1): _parseURL() HTTP://192.168.59.184:2002/?value=1 Debug( 6): _connect() Debug( 11): send() Debug( 11): _buildRequest() Debug( 12): _send() 126 Debug( 14): can't send Debug(30127): _onError handler error=-13 Debug(30128): _onDisconnect handler Debug(30128): _setReadyState(4) [36838] HTTP Status Code:-4 Debug(30129): responseText() Debug(30131): responseText() no data [43161] Ready State: 4 [43161] Push Sent Debug(36452): setTimeout(2) Debug(36452): setDebug(on) version 1.1.15 Debug(36452): open(GET, http://192.168.59.184:2002/?valu) Debug( 1): _parseURL() HTTP://192.168.59.184:2002/?value=0 Debug( 5): _connect() Debug( 9): send() Debug( 10): _buildRequest() Debug( 12): _send() 126 Debug( 14): can't send Debug(30845): _onError handler error=-13 Debug(30845): _onDisconnect handler Debug(30846): _setReadyState(4) [74011] HTTP Status Code:-4 Debug(30846): responseText() Debug(30849): responseText() no data [80021] Ready State: 4 [80021] Push Sent Debug(36857): setTimeout(2) Debug(36857): setDebug(on) version 1.1.15 Debug(36857): open(GET, http://192.168.59.184:2002/?valu) Debug( 1): _parseURL() HTTP://192.168.59.184:2002/?value=0 Debug( 5): _connect() Debug( 9): send() Debug( 10): _buildRequest() Debug( 12): _send() 126 Debug( 14): can't send [88459] Ready State: 0 [88460] Push Sent Debug(8435): setTimeout(2) Debug(8435): setDebug(on) version 1.1.15 Debug(8435): open(GET, http://192.168.59.184:2002/?valu) Debug( 1): _parseURL() HTTP://192.168.59.184:2002/?value=1 Debug( 6): _connect() Debug( 9): send() Debug( 9): _buildRequest() Debug( 12): _send() 126 Debug( 14): can't send Debug(21244): _onError handler error=-13 Debug(21245): _onDisconnect handler Debug(21245): _setReadyState(4) [109709] HTTP Status Code:-4 Debug(21246): responseText() Debug(21249): responseText() no data

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

[andrewk123]

I had a quick look at this. The restart appears to be caused by (in my example above) the second connection attempt de-allocating _client when the onDisconnect handler fires while the the third connection attempt is still active. The third attempt then tries to re-use the already deallocated _client causing the restart. As I said, I can work around this by looking for the http.readyState() to be 4 (not 0) (after the first connect attempt) and queuing/retrying subsequent messages until the previous attempt has timed out. This stops the resets.

However, we still have the issue that there is a (+/-) 30 sec timeout before the onDisconnect event turns up even though the application "knows" it "*can't send" after less than 20 ms. Any thoughts on how to abort the connection and/or fire the onDisconnect event? I've tried using the abort() command after a timeout however that has no effect. Any thoughts appreciated.

[miwied]

Hello, I have the excact same problems.

Here is my example code and here is the reboot msg.

[miwied]

@andrewk123 did you solve the timout problem?

[andrewk123]

I tried AsyncHTTPRequest_Generic and found the same issue, however Khoi was able to resolve it so I use that version now. It's functionally identical to asyncHTTPrequest. There were some small changes to integrate it but nothing that took more than a few minutes. The fix was in 1.4.0.

https://github.com/khoih-prog/AsyncHTTPRequest_Generic

[miwied]

@andrewk123 Hi first of all thanks for your answer!

Thats actually pretty funny because I struggeled for weeks to get either boblemaire's or khoih-progs library to work properly. After days of no success I created a issue which let khoih to make a new version with a fix. Here is his answer to my issue.

Unfortunately till today I didn't get a working version.. After the "fix" it still takes always 18 seconds to get a bad connection response. You can see my demo-code + debug output here.

Which microcontroller do you use?

[boblemaire]

Looks like a solution was found in another's fork.

[miwied]

@boblemaire Wich one?