-
Notifications
You must be signed in to change notification settings - Fork 52
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
queue stuck in INIT state on tarantool 3 #226
Comments
DerekBum
added a commit
that referenced
this issue
Apr 4, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait for all orphan instances on the init stage of the queue. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 4, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait for all orphan instances on the init stage of the queue. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 4, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait for all orphan instances on the init stage of the queue. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait in the background for all orphan instances. It is simular to lazy init for read-only instances. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait in the background for all orphan instances. It is similar to lazy init for read-only instances. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait in the background for all orphan instances. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of using watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still in the orphan mode. This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue was stuck in the `INIT` state. Now we wait in the background for all orphan instances. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 9, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 10, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 10, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 10, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 11, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 11, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 11, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 15, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 15, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now we wait in the background for instances, that are not running. It is similar to lazy init for read-only instances. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 15, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now if the instance is read-only, separate fiber is watching for updates of its mode. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
DerekBum
added a commit
that referenced
this issue
Apr 15, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now if the instance is read-only, separate fiber is watching for updates of its mode. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
oleg-jukovec
pushed a commit
that referenced
this issue
Apr 15, 2024
Sometimes, instance could enter the queue initialization while still not running (for example, left in the orphan mode). This resulted in "lazy start". But Tarantool does not call `box.cfg {}` after leaving orphan mode, so queue could stuck in the `INIT` state. Now if the instance is read-only, separate fiber is watching for updates of its mode. Note that this fix works only for Tarantool versions >= 2.10.0. This is because of used watchers. Closes #226
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
I tried to run cluster on tarantool 3 with queue on shard.
Everething was fine until i added a replicas to queue replicaset.
Sometimes after cluster start i got strange behavior: queue stuck in INIT state on RW instance.
Reproduce
Versions:
config.yaml
app/roles/billing.lua
The text was updated successfully, but these errors were encountered: