- Sun Mar 19, 2017 3:53 pm
#63964
Huh? You mean if the page says "Iterations: 140" in my browser after having refreshed in ~300ms intervals I shouldn't believe it?
Your feedback left me puzzled - at first. In my understanding the next iteration is primarily kicked off by the JavaScript reload in the browser not by closing the connection on the device.
Then I realized that the behavior depends on the browser. I was testing in Chrome. It closes/discards the connection even if the server doesn't explicitly close the connection on its end (due to `Connection: close` in the HTTP header I guess). So, it was all good but your comment (and jankop's) made me test with Safari and Firefox as well and they indeed only close the connection and reload after it times out.
You're right. I mixed up two things in haste. In terms of closed upvalues it's just essential that the "socket" in the on-receive callback is identified as `client` instead of re-using the `conn` variable.
So, I ran your unmodified code against 1.5.4.1 on ESP-01 with 512KB: all good, heap was stable (I stopped after 500 iterations). I did the same against 2.0 on a NodeMCU devkit: it eventually crashed.
And then it dawned on me. I had suspected from the very beginning that this might be another lw IP TIME_WAIT issue but I had dismissed that after my initial tests had succeeded.
Just two days ago we merged https://github.com/nodemcu/nodemcu-firmware/pull/1838 which fixes the above issue. So, I built another 2.0 firmware from the dev branch (latest revision) and ran your code again. And sure enough after an initial drop the heap stabilized. Considering the TIME_WAIT implications this makes total sense. After the test I killed the browser tab, waited a while and checked the heap again.
Again, this makes sense. The difference between 35k and 40k are the sockets in TIME_WAIT that were cleared in the meantime.
gschulz wrote:I'm not sure you were looking at what you thought you were looking at. Firstly, if you were using the test code you presented, it would not have worked. When you modified my code, you eliminated the client:close() statement that would be necessary to kick off the next iteration.
Huh? You mean if the page says "Iterations: 140" in my browser after having refreshed in ~300ms intervals I shouldn't believe it?
Your feedback left me puzzled - at first. In my understanding the next iteration is primarily kicked off by the JavaScript reload in the browser not by closing the connection on the device.
Then I realized that the behavior depends on the browser. I was testing in Chrome. It closes/discards the connection even if the server doesn't explicitly close the connection on its end (due to `Connection: close` in the HTTP header I guess). So, it was all good but your comment (and jankop's) made me test with Safari and Firefox as well and they indeed only close the connection and reload after it times out.
gschulz wrote:moving the conn:on("send"...) callback to the conn:on("receive"...) callback should have no affect
You're right. I mixed up two things in haste. In terms of closed upvalues it's just essential that the "socket" in the on-receive callback is identified as `client` instead of re-using the `conn` variable.
So, I ran your unmodified code against 1.5.4.1 on ESP-01 with 512KB: all good, heap was stable (I stopped after 500 iterations). I did the same against 2.0 on a NodeMCU devkit: it eventually crashed.
And then it dawned on me. I had suspected from the very beginning that this might be another lw IP TIME_WAIT issue but I had dismissed that after my initial tests had succeeded.
Just two days ago we merged https://github.com/nodemcu/nodemcu-firmware/pull/1838 which fixes the above issue. So, I built another 2.0 firmware from the dev branch (latest revision) and ran your code again. And sure enough after an initial drop the heap stabilized. Considering the TIME_WAIT implications this makes total sense. After the test I killed the browser tab, waited a while and checked the heap again.
Code: Select all
...
34864
=node.heap()
40184Again, this makes sense. The difference between 35k and 40k are the sockets in TIME_WAIT that were cleared in the meantime.
