Hyper-Express sometimes leaves request connections hanging about hyper-express HOT 7 CLOSED

This may be an underlying limitation of uWebsockets.js only being able to run on one port in a given environment but I do know that clustered workers/worker threads can run HyperExpress/uWebsockets.js instances on the same port for more performance. I would recommend you try and see if you can recreate this behavior in just uWebsockets.js to confirm that its a uWS limitation not a bug in HyperExpress.

Also, clearing node_modules should not be a solution unless you/some program is making changes to the code inside of node_modules which also should not be occurring at any cost as its forbidden for any package to do so.

from hyper-express.

@kartikk221 here is an example of how to shutdown the uWS.js server:

https://github.com/uNetworking/uWebSockets.js/blob/master/examples/GracefulShutdown.js#L13

Hi, this is already done by HyperExpress. See src/components/Server.js from lines 65 - 110.

from hyper-express.

To build on my recommendation in the previously mentioned issue, this is likely an issue with one of your middlewares rather than LiveDirectory or any such package as requests hanging up means that the response is not being sent by the server which in your logic can only occur if one of the middlewares hold up the execution for some requests due to bad logic.

from hyper-express.

Hi Kartik, thanks for the suggestion. I made a small min.js file in that repo and can reproduce the error.

rm -rf node_modules fixes the issue.

I am able to reproduce by starting multiple terminals with node min.js. Subsequent instances do not say "port in use" they just start. I can reproduce this even after rebooting.

The 2nd instance does not get a "port in use" error, and browser GET triggers console.log() in the 1st terminal.

Starting a 3rd, no error, and browser GET triggers 2nd terminal to console.log()

I'm using Ubuntu 20.04 WSL on Windows 10. If I reboot Windows, I can reproduce the error.

If I try to start a different web server on the hyper-express port, I get an error.

If I try to start hyper-express on a port in use by another web server, I get an error.

Obviously, I don't need to run more than one instance on the same port - it is just surprising that 2 hyper-express will try to use the same port.

The original issue will happen after closing all instances and starting a single new one.

from hyper-express.

That uWS feature as the cause makes sense.

Re: deleting node_modules, I agree with you in theory, but in practice there appeared to be some state in node_modules, or some meta-state about node_modules that deleting reset. node-gyp and C++ node modules are outside my expertise. Anyways, it also surprised me.

from hyper-express.

That is very odd, I guess you may be able to open an issue in the uWebsockets.js repository to get help there directly from the creator. I double checked the Server.listen() function and it is simply a wrapper of the uWS.TemplatedApp.listen() function so whatever behavior is causing this to occur is out of HyperExpress's control. I personally run multiple instances of the latest HyperExpress version on my development server on different ports for different microservices and they all run fine so I am not sure why you are experiencing this issue. I'll go ahead and close this issue for now as it seems to be behavior specific to your setup and If is incorrect behavior then it has to be dealt with by the creator of uWebsockets.js. Feel free to post in this issue If you discover further information regarding this.

from hyper-express.

@kartikk221 here is an example of how to shutdown the uWS.js server:

https://github.com/uNetworking/uWebSockets.js/blob/master/examples/GracefulShutdown.js#L13

from hyper-express.