Closed printercu closed 4 years ago
This makes it impossible to use queue in cartridge, because it starts instances in read_only mode.
NB: Aside of implementing postponing of queue initialization until box will leave read-only mode we need to verify whether we give proper errors when a write operation (say, take()
) is requested in the read only mode.
Do you think that tarantool's error Can't modify data because this instance is in read-only mode.
is not enough?
The message is okay.
It is required to understand the DoD of the issue ( @Totktonada ). I can propose the following solutions:
The reasons, why in read_only mode the persistent queues in unavailable:
Explicit queue.init()
would be much better. require
should be idempotent and do the same things no matter box is configured or not. Sure, this will be not backward-compatible but much more expected behavior.
Explicit
queue.init()
would be much better.require
should be idempotent and do the same things no matter box is configured or not. Sure, this will be not backward-compatible but much more expected behavior.
Hi. If I understand correctly, your proposal doesn't solve the problems with toggling and persistent queues. Are you suggesting something like: "If you are trying to execute init(), you should do box.cfg{read_only = false} before"?
Breaking backward compatibility is a last resort. I think this is not our way.
Like every other DDL (ex., space creation) it would be wrapped with if not box.cfg.read_only then
(or if options.is_master then
in cartridge).
@printercu Would lazy start (1st option of the proposed by Leonid) resolve the problem with cartridge?
I would implement lazy starting here and return later to switching from/to read_only mode at any time if there will be demand.
Well, maybe. I haven't seen in the other rocks patching box.cfg after it has been called, and don't know if there could be any pitfalls.