-
Notifications
You must be signed in to change notification settings - Fork 31
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
The case when storage and router iproto fiber is cancelled #341
Comments
Actually, package.loaded['vshard'] = nil
local vshard = require('vshard') As user expects everything to be reloaded, I suppose we should implement atomic reload of the whole Speaking of restoring fibers after explicit kill of them, we can do that in Lines 173 to 177 in dd70cfb
As this method is invoked in replicaset_master_call fibers will be restored too.
|
Most of replicaset methods like |
Currently if we kill net.box's fibers the connection goes into `error_reconnect` state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is `dead` and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill net.box's fibers the connection goes into 'error_reconnect' state. However, it's not reconnecting anymore. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. So, after fiber kill wait until it's really dead and make a request only after that. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, from 2.10.1 worker fiber is invincible and cannot be killed at all. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
The problem is that recovery fiber wakes up earlier than we want it to do so. This leads to the test output which we don't expect. Let's block recovery fiber before making any changes to the `_bucket`. It'll start again as soon as the instance is restarted. Needed for tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. However, reconnecting doesn't happen automatically in tarantool 2.10.0, as there's no way to determine if the fiber is dead other than checking the error message of the connection, which is not a good practice as this check can be easily trigerred false-positively. Closes tarantool#341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. Closes tarantool#341
The problem is that recovery fiber wakes up earlier than we want it to do so. This leads to the test output which we don't expect. Let's block recovery fiber before making any changes to the `_bucket`. It'll start again as soon as the instance is restarted. Needed for #341
Currently if we kill the worker fiber of the connection, which was initialized with 'reconnect_after' option, this connection goes into 'error_reconnect' or 'error' state (depends on tarantool version). Reconnecting doesn't happen in both cases and the only way for user to return router to working order is reloading or manual restoring of the connections. This patch introduces reconnecting in that case. It should be used wisely, though. Fiber's killing doesn't happen instantly and if the user doesn't wait util fiber's status is 'dead' and makes the request immediately, exception will be probably thrown as the fiber can die in the middle of request. Closes #341
Privet
There is case when something happened and storage fiber is cancelled (for e.g. cartridge hotreload or any other fiber killer).
Some affected snippet
The question is, how to restart netbox connection under vshard.router? Or is it possible to be done on vshard side?
The text was updated successfully, but these errors were encountered: