-
Notifications
You must be signed in to change notification settings - Fork 30
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
Router should not start listen before it is ready to accept requests #194
Comments
5d935fc should resolve the storage part of the problem |
Serpentian
added a commit
to Serpentian/vshard
that referenced
this issue
Jul 6, 2022
This patch introduces protecting router's API while its configuration is not done as accessing these functions at that time is not safe and can cause low level errors like 'bad arguments' or 'no such function'. Now all non-trivial vshard.router functions are disabled until `vshard.router.cfg` (or `vshard.router.new`) is finished and error is raised in case of an attempt to access them. Manual API's enabling/disabling is also introduced in this patch. Closes tarantool#194 Closes tarantool#291 @TarantoolBot document Title: vshard.router.enable/disable() `vshard.router.disable()` makes most of the `vshard.router` functions throw an error. As Lua exception, not via `nil, err` pattern. `vshard.router.enable()` reverts the disable. `router_object:enable()/disable()`, where `router_object` is the return value of `vshard.router.new()`, can also be used for manual API access configuration for the specific non-static router. By default the router is enabled. Additionally, the router is forcefully disabled automatically until its configuration is finished and the instance finished recovery (its `box.info.status` is `'running'`, for example). Auto-disable protects from usage of vshard functions before the router's global state is fully created. Manual router's disabling helps to achieve the same for user's application. For instance, a user might want to do some preparatory work after `vshard.router.cfg` before the application is ready. Then the flow would be: ```Lua vshard.router.disable() vshard.router.cfg(...) -- Do your preparatory work here ... vshard.router.enable() ``` The behavior of the router's API enabling/disabling is similar to the storage's one.
Gerold103
pushed a commit
that referenced
this issue
Jul 8, 2022
This patch introduces protecting router's API while its configuration is not done as accessing these functions at that time is not safe and can cause low level errors like 'bad arguments' or 'no such function'. Now all non-trivial vshard.router functions are disabled until `vshard.router.cfg` (or `vshard.router.new`) is finished and error is raised in case of an attempt to access them. Manual API's enabling/disabling is also introduced in this patch. Closes #194 Closes #291 @TarantoolBot document Title: vshard.router.enable/disable() `vshard.router.disable()` makes most of the `vshard.router` functions throw an error. As Lua exception, not via `nil, err` pattern. `vshard.router.enable()` reverts the disable. `router_object:enable()/disable()`, where `router_object` is the return value of `vshard.router.new()`, can also be used for manual API access configuration for the specific non-static router. By default the router is enabled. Additionally, the router is forcefully disabled automatically until its configuration is finished and the instance finished recovery (its `box.info.status` is `'running'`, for example). Auto-disable protects from usage of vshard functions before the router's global state is fully created. Manual router's disabling helps to achieve the same for user's application. For instance, a user might want to do some preparatory work after `vshard.router.cfg` before the application is ready. Then the flow would be: ```Lua vshard.router.disable() vshard.router.cfg(...) -- Do your preparatory work here ... vshard.router.enable() ``` The behavior of the router's API enabling/disabling is similar to the storage's one.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First
vshard.router.cfg
creates internal static router object, and configures it. During configuration it callsbox.cfg{listen = ..., ...}
, but before the configuration is actually finished. It leads to a problem, that router has already started listening, but is not ready to serve requests yet. The same problem exists for storage - box.cfg is called before _bucket is created.The text was updated successfully, but these errors were encountered: