◼ Apache Ignite Product Properties

Apache Ignite 2

Thin client partition awareness and affinity routing

Public product properties reconstructed from test evidence.

Thin client partition awareness and affinity routing

This page is a public product-spec reconstruction from Apache Ignite 2 test sources at revision 486a6367610c4c891b729e89373695ef83165345.

Partition-awareness tests describe how the thin client uses topology and affinity metadata to route supported operations toward the best known server connection.

User-facing guarantees

Traceable requirements

Only negative or ambiguous test status is annotated after a test name, for example status=failed, status=flaky, status=ignored, or status=mixed.

THIN-PA-STABLE-01 — single-key cache operations route by affinity on stable topology

Requirement: For stable topologies, partition-aware routing must handle primitive keys, complex keys, affinity-key annotations/configuration, replicated caches, backup counts, node filters, and custom affinity mapper cases.

Why: Applications get lower-latency routing without manually selecting server endpoints.

Boundary: Mostly evidence: routing/protocol behavior is asserted more directly than operation result semantics.

Evidence tests:

THIN-PA-GROUPING-01 — affinity mappings are reused only when compatible

Requirement: The client must group caches with equivalent affinity mappings and request separate mappings when effective affinity differs.

Why: This limits metadata traffic without routing requests through an incompatible mapping.

Boundary: Evidence from protocol/request-count assertions; does not prove all custom affinity combinations.

Evidence tests:

THIN-PA-AUX-OPS-01 — scan query, set and atomic-long operations participate where supported

Requirement: Partition-bound scan queries, IgniteSet operations, collocated sets, and AtomicLong reads must use affinity-aware routing in tested cases.

Why: Non-cache-key APIs should benefit from affinity metadata when their data placement is known.

Boundary: Evidence; proves routing participation, not full semantic correctness of every operation.

Evidence tests:

THIN-PA-TOPOLOGY-01 — routing refreshes after topology/session changes

Requirement: The client must refresh or recreate routing state after connection loss, node join/leave, cluster restart with lower/same topology version, session close-before-handshake, and create-session-after-close.

Why: Long-running clients should continue routing correctly after operational topology changes.

Boundary: Weaker where tests exercise timing/session races and fallback paths; exact fallback target is not always established.

Evidence tests:

THIN-PA-MULTIDC-01 — data-center aware routing chooses configured local endpoints

Requirement: With multi-DC settings, partition-aware and non-partition-aware requests must prefer allowed/local endpoint sets and handle no-node-in-DC cases as tested.

Why: Operators can bias thin-client traffic toward the intended data center.

Boundary: Weaker evidence for configured examples only; not an outage-handling or fairness guarantee.

Evidence tests:

THIN-PA-RES-METRICS-01 — resources and metrics reflect partition-awareness lifecycle

Requirement: Partition-awareness resources must be released after client close/cache destroy, metrics must count affinity hits/misses, and balancing should distribute connections in the tested setup.

Why: Users need observable routing quality and no retained routing state after lifecycle cleanup.

Boundary: Evidence; balancing is scenario-bound and not a general fairness proof.

Evidence tests:

Important boundaries