-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: custom dispatch connection close #2445
Comments
It is recommended to use the second dispatcher, otherwise problems may occur |
The approach of caching the dispatch results by connection ID The best implementation of the Round-Robin I could come up with does not seem reliable when the next request comes in before the previous one finishes and closes the connection: |
The fallback dispatch by the Client ID |
Hm, multiple requests can be handled through the same persistent connection. So, there will be multiple calls to the dispatch function with request data ( @twose, @matyhtf, |
Imagine a custom dispatch function based on an HTTP request message, such as request path, host, or cookies, etc. It would extract a request identifier from the request message and resolve it to a worker ID via the standard formula
crc32($requestId) % $server->setting['worker_num']
.Naive implementation of dispatch by URL path:
There's a problem with the straightforward implementation - the dispatcher function is called 2 times for a single request:
$type == 10
$type == 4
Unlike the 1st call, the 2nd call does not have access to the request data, so it cannot perform the same worker ID resolution as the 1st call to dispatch to the same worker process.
Revised implementation caching result of the 1st call:
The implementation has become considerably more complicated and it now requires to maintain the state, so it cannot be a simple function anymore. It would be great to avoid overcomplicating the implementation of dispatchers by freeing them from handling the connection closure.
Conceptual questions:
$fd
as cache key?Thanks in advance for responding to this ticket which is a question rather than an issue.
The text was updated successfully, but these errors were encountered: