- Tue Dec 05, 2017 2:55 am
#72314
igrr wrote:Ok, so far I wasn't able to set up this environment (I'm having some java issues) but the problem with this sketch is clear.
On the ESP side, you are doing active close of TCP connection (i.e. esp initiates connection close). Therefore, TCP connection enters TIME_WAIT state and resources are not released for about two minutes.
So after a few requests esp runs out of RAM.
You need to do something similar to HTTP "Connection: close" header, instructing the server to close the connection. This way ESP will do passive close, and memory used by TCP connection will be released immediately.
I was having various inconsistent issues with the ESP8266 nor responding in random patterns, iterations, and time frames. This despite resetting the ESP8266 and running the exact same number and timing of HTTP requests to the ESP8266. I know as the application HTTP requests are tightly controlled in timing and type of request. This pattern lasted for over a week. This was my first ESP8266 application and was on complex side in terms of logic. This complex application was on top of the learning curve of the ESP8266. The first cut of just basic code was not working as I would like and more research lead to a different approach for the basic approach for the ESP8266.
I did web searching as I expected others to have likely had the same issues. Oddly it seemed many search results simple were not related in any manner, or the issue had not been reported, or the reporting of the issue was a bit skewed (Issues can often be skew in what is reported vs real problem as that is just a common fact for many valid reasons.). After several hours of searching that included this site I decided on this site by illiterately going through the bugs and issues postings one by one until I discovered this thread in the Bug Reports topic group.
Some more research that again was thin on what was suggested as a cause for the OP. I did find some material related to the HTTP headers, but sparse, often lacking much about the format, what means, what is assumed, and how to pass with the application I was using to access the ESP8266. I am still not clear yet if using a browser will cause the memory leak issues in stack. I am assuming this was what was likely the cause of the problem I was experiencing as much as rather too random for a clear exact repeatable in timing and number of HTTP requests to the ESP8266 in my case and will always be for this application.
So far, now almost 24 hours later not one miss of data, therefore no lockup of the ESP8266. I was not willing to place the ESP8266 by a computer to monitor the serial port to know what in fact happened. I assumed some sort of sketch crash in end and likely some issues/messages in the bumpy random patterns of few minutes to a few hours to no recovery even hours later. This positive outcome I believe due to igrr last post. I have also confirmed via existing in the base code I initially wrote not knowing this issue would exist the heap is stable. At some point with a different ESP8266 I will conduct tests pre the changes I last made to the application accessing the ESP8266 (not an ESP8266) so I can see the heap patterns and also if my assumption of a ESP8266 crash that will output some information on the serial port of the crashed and random pattern issues. This will again be done in the same controlled pattern as that is how the application is that accesses the ESP8266.
Thanks again for this thread. I do have related questions, but I want to see if I can figure the answers out and/or with help of more research.
John L. Males
Toronto, Ontario
Canada
05 December 2017 02:25 - 02:55
