You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 5
Next »
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
Name | Code |
---|
OP_BINARY_CONFIGURATION_GET | 3004 |
Response |
---|
bool | compactFooter |
byte | binaryNameMapperMode (0 = basic full name, 1 = basic simple name, 2 = custom) |
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
// TODO Links to discussions on the devlist, if applicable.
Reference Links
PoC: https://github.com/apache/ignite/pull/8733
Tickets
Unable to render Jira issues macro, execution error.