Skip to content
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

Closed
Gerold103 opened this issue Sep 11, 2019 · 1 comment · Fixed by #342
Closed

Router should not start listen before it is ready to accept requests #194

Gerold103 opened this issue Sep 11, 2019 · 1 comment · Fixed by #342
Assignees
Labels
bug Something isn't working customer teamS Scaling
Milestone

Comments

@Gerold103
Copy link
Collaborator

First vshard.router.cfg creates internal static router object, and configures it. During configuration it calls box.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.

@Gerold103 Gerold103 added bug Something isn't working customer labels Sep 11, 2019
@Gerold103 Gerold103 added this to the 0.2 milestone Sep 11, 2019
@kyukhin kyukhin added the teamS Scaling label Sep 17, 2021
@sergos
Copy link
Contributor

sergos commented Jan 25, 2022

5d935fc should resolve the storage part of the problem

@Serpentian Serpentian linked a pull request Jun 29, 2022 that will close this issue
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.
@sergos sergos added the 1sp label Jul 20, 2022
@Serpentian Serpentian self-assigned this Aug 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working customer teamS Scaling
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants