-
Notifications
You must be signed in to change notification settings - Fork 54
Add the "lazy start" technique to initialization stage #131
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
Conversation
The similar problem: tarantool/expirationd#37 |
587c7a7
to
786c94f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, consider my doubts and fears below.
786c94f
to
7e982eb
Compare
When the script is long enough to contain multiple function, it's nice to have a function like "main" instead of just a linear flow code. The patch moves the initialization code of the queue module into a separate function.
7e982eb
to
5c3f452
Compare
Previously, if an instance was started in read_only mode, it could throw an error when initializing the queue module, like this: "Can't modify data because this instance is in read-only mode". To avoid such behavior the "lazy start" technique has been added: The queue module is loaded immediately if the instance was configured with read_only = false. Otherwise, a start is delayed until the instance will be configured with read_only = false. Closes #122
5c3f452
to
6dc58a7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot say that I'm comfortable with complexity we have there, but I don't want to push Leonid to experiment around different similar variants (given one with the __call metamethod replacing, with a proxy table whose __call invokes a real reconfiguration function, with registering a callback using box.on_reload_configuration) to understand what will looks better.
Since it should resolve the issue and I don't see anything that would lead to problems in use, it is okay for me.
Previously, if an instance was started in read_only mode,
it could throw an error when initializing the queue module,
like this: "Can't modify data because this instance is in
read-only mode".
To avoid such behavior the "lazy start" technique has been added:
The queue module is loaded immediately if the instance was
configured with read_only = false. Otherwise, a start is delayed
until the instance will be configured with read_only = false.
Closes #122
ChangeLog: add the ability to start an instance with a loaded queue module in read-only mode. In this case, a start of the module will be delayed until the instance will be configured with read_only = false.