Drop graceful shutdown feature flag #262

DifferentialOrange · 2022-11-11T10:14:12Z

IPROTO_FEATURE_GRACEFUL_SHUTDOWN feature flag was dropped in tarantool/tarantool@2e9cbec commit before release, so there is no traces of this flag in Tarantool releases and it is possible that some new meaning would be used for IPROTO_FEATURE_X = 4, so we must drop it too to not confuse users.

The text was updated successfully, but these errors were encountered:

DifferentialOrange · 2022-11-11T10:37:35Z

Follows #206

Graceful shutdown was introduced in Tarantool with [1]. A week later it was reworked with [2]. So the timeline is as follows. - Graceful shutdown is introduced, new feature flag is added and the protocol version is bumped to 4. - Graceful shutdown is reworked, feature flag is dropped and the protocol version is dropped to 3. - Next Tarantool version released. So the idea for users is "IPROTO_FEATURE_GRACEFUL_SHUTDOWN and protocol version 4 never existed". It also means that any new feature flag may have value `4` (same as IPROTO_FEATURE_GRACEFUL_SHUTDOWN), but with completely different meaning. IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag was added in [3] by mistake due to misunderstanding the event timeline. This patch removes the flag. Since `_features` dict is an internal of a connection object, the change shouldn't break anything for users. 1. tarantool/tarantool@6f29f9d 2. tarantool/tarantool@2e9cbec 3. #243 Closes #262

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior. After this patch, the request will be send on `Connect`. Connector will use protocol version that is minimal of connector version (now it's 3) and server version. Feature will be enabled if both client and server supports it (for now client does not support any features from the list). Unknown request type error response is expected for pre-2.10.0 versions. In this case, protocol version would be ProtocolVersionUnsupported (-1) and no features would be enabled. For now it doesn't seems like exposing protocol version and enabled features is useful for a client so private variables are used to store this info. Getters added in export_test for tests. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [2] for more info. 1. tarantool/tarantool#6253 2. tarantool/tarantool-python#262 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior. After this patch, the request will be send on `Connect`. Connector stores server info in connection internals. After that, user may call `IsProtocolVersionSupported` and `IsProtocolFeatureSupported` handles to check if it is possible to use a feature. `IsProtocolFeatureSupported` iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [3]. Benchmark tests show that this check is rather fast (0.5 ns on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [2] for more info. 1. tarantool/tarantool#6253 2. tarantool/tarantool-python#262 3. https://stackoverflow.com/a/52710077/11646599 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior. After this patch, the request will be send on `dial`, where authentication is performed. Connector stores server info in connection internals. After that, user may call API handles to check if it is possible to use a feature. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [2]. Benchmark tests show that this check is rather fast (0.5 ns for client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [3] for more info. 1. tarantool/tarantool#6253 2. https://stackoverflow.com/a/52710077/11646599 3. tarantool/tarantool-python#262 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send the schema version and supported features and receive server-side schema version and supported features information to tune its behavior. After this patch, the request will be send on `dial`, where authentication is performed. Connector stores server info in connection internals. After that, user may call API handles to check if it is possible to use a feature. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [2]. Benchmark tests show that this check is rather fast (0.5 ns for both client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [3] for more info. 1. tarantool/tarantool#6253 2. https://stackoverflow.com/a/52710077/11646599 3. tarantool/tarantool-python#262 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send client protocol version and supported features and receive server protocol version and supported features information to tune its behavior. After this patch, the request will be sent on `dial`, before authentication is performed. Connector stores server info in connection internals. After that, user may call API handles to check if it is possible to use a feature. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [2]. Benchmark tests show that this check is rather fast (0.5 ns for both client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [3] for more info. 1. tarantool/tarantool#6253 2. https://stackoverflow.com/a/52710077/11646599 3. tarantool/tarantool-python#262 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send client protocol version and supported features and receive server protocol version and supported features information to tune its behavior. After this patch, the request will be sent on `dial`, before authentication is performed. Connector stores server info in connection internals. User can also set option RequiredProtocolVersion and RequiredFeatures to fast fail on connect in server (or even client) does not provide some expected feature. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [2]. Benchmark tests show that this check is rather fast (0.5 ns for both client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [3] for more info. 1. tarantool/tarantool#6253 2. https://stackoverflow.com/a/52710077/11646599 3. tarantool/tarantool-python#262 Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send client protocol version and supported features and receive server protocol version and supported features information to tune its behavior. After this patch, the request will be sent on `dial`, before authentication is performed. Connector stores server info in connection internals. User can also set option RequiredProtocolVersion and RequiredProtocolFeatures to fast fail on connect if server does not provide some expected feature, similar to net.box opts [2]. It is not clear how connector should behave in case if client doesn't support a protocol feature or protocol version, see [3]. For now we decided not to check requirements on client side. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [4]. Benchmark tests show that this check is rather fast (0.5 ns for both client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [5] for more info. In latest master commit new feature with code 4 and protocol version 4 were introduced [6]. 1. tarantool/tarantool#6253 2. https://www.tarantool.io/en/doc/latest/reference/reference_lua/net_box/#lua-function.net_box.new 3. tarantool/tarantool#7953 4. https://stackoverflow.com/a/52710077/11646599 5. tarantool/tarantool-python#262 6. tarantool/tarantool@948e5cd Closes #120

Since version 2.10.0 Tarantool supports feature discovery [1]. Client can send client protocol version and supported features and receive server protocol version and supported features information to tune its behavior. After this patch, the request will be sent on `dial`, before authentication is performed. Connector stores server info in connection internals. User can also set option RequiredProtocolInfo to fast fail on connect if server does not provide some expected feature, similar to net.box opts [2]. It is not clear how connector should behave in case if client doesn't support a protocol feature or protocol version, see [3]. For now we decided not to check requirements on the client side. Feature check iterates over lists to check if feature is enabled. It seems that iterating over a small list is way faster than building a map, see [4]. Benchmark tests show that this check is rather fast (0.5 ns for both client and server check on HP ProBook 440 G5) so it is not necessary to cache it in any way. Traces of IPROTO_FEATURE_GRACEFUL_SHUTDOWN flag and protocol version 4 could be found in Tarantool source code but they were removed in the following commits before the release and treated like they never existed. We also ignore them here too. See [5] for more info. In latest master commit new feature with code 4 and protocol version 4 were introduced [6]. 1. tarantool/tarantool#6253 2. https://www.tarantool.io/en/doc/latest/reference/reference_lua/net_box/#lua-function.net_box.new 3. tarantool/tarantool#7953 4. https://stackoverflow.com/a/52710077/11646599 5. tarantool/tarantool-python#262 6. tarantool/tarantool@948e5cd Closes #120

DifferentialOrange added teamE labels Nov 11, 2022

DifferentialOrange mentioned this issue Nov 11, 2022

internal: drop graceful shutdown feature flag #263

Merged

DifferentialOrange closed this as completed in #263 Nov 11, 2022

DifferentialOrange mentioned this issue Nov 11, 2022

api: support iproto feature discovery tarantool/go-tarantool#226

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drop graceful shutdown feature flag #262

Drop graceful shutdown feature flag #262

DifferentialOrange commented Nov 11, 2022 •

edited

Loading

DifferentialOrange commented Nov 11, 2022

Drop graceful shutdown feature flag #262

Drop graceful shutdown feature flag #262

Comments

DifferentialOrange commented Nov 11, 2022 • edited Loading

DifferentialOrange commented Nov 11, 2022

DifferentialOrange commented Nov 11, 2022 •

edited

Loading