reloading and latest files

[rbro]

Workerman is great. I'm running into 2 issues with reloading that may be the same issue that I was hoping you could assist with:

I have a script similar to the example for "The following code will be automatically updated after reload" on https://manual.workerman.net/doc/en/faq/reload-principle.html.

This scenario is working as expected:

1. in terminal 1, run "start"
2. in terminal 2, run "curl http://127.0.0.1:2345" and get the expected output.
3. edit MessageHandler.php to change the output
4. in terminal 2, run "reload -g"
5. in terminal 2, run "curl http://127.0.0.1:2345". I get the new output as expected.

Now instead I tried the below:

1. in terminal 1, run "start"
2. in Firefox or Chrome, go to http://127.0.0.1:2345 and get the expected output.
3. in terminal 2, run "curl http://127.0.0.1:2345" and get the expected output.
4. edit MessageHandler.php to change the output
5. in terminal 2, run "reload -g"

At this point, I'm seeing 2 possible issues: Issue 1) If I run "curl http://127.0.0.1:2345", sometimes I get the new output and sometimes I get the old output. Issue 2) If I go to http://127.0.0.1:2345 in Firefox or Chrome, I don't get the new output.

The only way I've been able to resolve it is by closing Firefox or Chrome. Then both scenarios work as expected.

My questions are:

1. For issue 1, is Workerman routing the request to the old process even though it should be shutting down?
2. For issue 2, my guess is because the web browser is holding onto the connection in some form? Is there a way to prevent it?

Thank you for your help.

[walkor]

Regarding the issues you're experiencing, here's the explanation:

1. When using reload -g, Workerman waits for all connections to close safely before restarting processes to load new code. Browser requests typically maintain persistent connections, preventing some processes from restarting immediately.

2. This results in both old and new versions of processes running simultaneously:

   • Restarted processes (running new code)
   • Old processes still handling browser connections (running old code)

3. Solutions:

   • Use php start.php reload (without -g) to restart immediately after completing current requests.
   • Or actively close connections after each response: $connection->close($response);

[rbro]

Thanks for your help. I thought that reload -g would allow current requests to complete, but I see now that reload does too. Is that correct that both allow current requests to complete? If so, is there a scenario where reload -g would be preferred?

[walkor]

Both reload -g and the standard reload will wait for current requests to complete before restarting.

While the standard reload does ensure that ongoing requests finish, there is a theoretical edge case: Due to network latency, a new request might arrive just as the process is about to exit after completing current requests, potentially causing that request to go unprocessed. However, this scenario is extremely rare, and in most cases, the standard reload is sufficient.

reload -g provides 100% safety by waiting until all internal connections are fully closed before restarting. It guarantees that no active connections remain when reloading the code.

In summary, reload -g is the safer option because it ensures all connections are completely terminated before performing the reload. However, for most developers, using the standard reload is perfectly adequate.

[rbro]

Thanks for the detailed explanation. Do you happen to know which of the 2 reload mechanisms nginx uses when you pass it the SIGHUP signal?

https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control