https://toitlang.org/ logo
Powered by
Issue with HTTP servers freezing (including jag?)
# help
a
After some time of code running, I end up not being able to use jag to send a new container to my ESP I just get 
Error: Get "http://192.168.68.66:9000/identify": context deadline exceeded
Any tips of debugging this further? I also noticed, that If I am running my own HTTP server on the ESP, this also seems to stop responding. The flip side of this is that the rest of the code in other tasks in the container continue to run as expected (including sometihng emiting stuff over UDP)
f
One thing to look out for is that the http-server, by default, only accepts a limited amount of connections. Sometimes that stalls/freezes the browser. Try to increase the 
--max-tasks
of the 
Server
constructor to something higher.
The last commit to the http-package is:
Copy code
Add '--max-task' to server examples. (#145)

Better to expose the argument in examples to make sure users don't
forget about it on the host.
The commit message mentions the host, but it might also be needed on the device.
That said. It doesn't explain why the Jaguar server would stop responding.
a
Yeah, I tried fiddling with the --max-tasks and didnt appear to be able to make it behave any differently is max-task per connection then, not per request? Good to know! Everything felt like it might be further down the stack (due to the apparent lockup of jag on :9000 too I'll see if I can play around with it a bit more in the coming days or weeks
f
Maybe @kasperl has an idea of what could be wrong.
a
of course it could be a hardware problem again or something 😄
f
you never know 🙂 but definitely hard to debug.
a
My favourite 😉
I can vaugly replciate similar behaviour with my standard dev board too My own http servers seems to stop responding, and when trying to do a jag run i get something like
Copy code
jag --device 192.168.68.77 run ./src/lb.toit
Scanning for  device with address: '192.168.68.77'
Error: Get "http://192.168.68.77:9000/identify": context deadline exceeded
f
Is there anything on the device-output that indicates a problem there?
a
Nope, and the container that I'm running there continue to run as normal
f
weird.
a
I guess I could attach a debugger, but that might have to wait for another week 🤦
f
It's a question what goes wrong. I would probably try to instrument the http package to see if that's where the error is.
PreviousNext
Powered by