Motivation

Thin clients currently require manual binary configuration for settings like compact footer and simple/full name mapper, which is complicated and error-prone.

Description

Extend the protocol to retrieve those settings automatically on start.

Feature Flag

BINARY_CONFIGURATION bitmask feature flag lets the client know that binary configuration can be requested.

Operation

OP_BINARY_CONFIGURATION_GET

Assumptions

• An alternative approach is to include this information into the handshake, which eliminates an extra request. However, a single partition-aware client performs a handshake with multiple server nodes. Binary configuration is guaranteed to be the same on all nodes in the cluster, so the client only needs to request it once. As a result, it is more efficient to perform one extra request than extending the handshake message.
• When "custom" mapper type is returned by the server, client is supposed to check that local BinaryConfiguration has a custom name mapper defined, and log/throw and error otherwise. We could return the type name of the custom mapper from the server, but it is of little use - we can't validate the client-side type name in non-Java clients, and even with Java client the class name can be different.

Discussion Links

Dev List: IEP-66: Thin Client Automatic Binary Configuration

Reference Links

PoC: https://github.com/apache/ignite/pull/8733

Tickets

Unable to render Jira issues macro, execution error.