◼ Apache Ignite Product Properties

Apache Ignite 2

Persistence cache dump export, reading, validation and cleanup

Public product properties reconstructed from test evidence.

Persistence cache dump export, reading, validation and cleanup

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

Cache-dump tests describe the operator-visible contract for creating, reading, validating, filtering, throttling, encrypting, and cleaning dump artifacts.

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.

DUMP-READ-EXPORT-01 — dumps are readable cache-data and metadata exports

Requirement: Created dumps must be readable through ordinary object, binary-object, and raw internal-object access paths and preserve selected metadata/version details.

Why: Operators and tooling need a dump artifact that can be inspected independently of live cache APIs.

Boundary: Mixed-strength evidence; not a full restore or disaster-recovery specification.

Evidence tests:

DUMP-FILTER-LOCATION-01 — dump creation respects filters, copy selection and locations

Requirement: Dump creation must honor node/cache-group filters, primary-copy de-duplication, explicit/custom dump locations, custom data storage paths, lazy snapshot directory creation, and no-cache/config-only preconditions.

Why: Operators need predictable artifact placement and scope control.

Boundary: Evidence from selected topology/storage layouts and exact precondition failures.

Evidence tests:

DUMP-CONCURRENT-CUT-01 — dump represents a stable cut under controlled concurrent writes

Requirement: Dump creation under controlled concurrent inserts, updates, removals, EntryProcessor mutations, expiry, and restart/streamer scenarios must produce a consistent readable artifact.

Why: A dump must be usable while applications continue changing data in supported scenarios.

Boundary: Concurrent/restart evidence is weaker than direct functional assertions; tests are bounded harnesses, not exhaustive isolation proofs.

Evidence tests:

DUMP-VALIDATION-01 — validation reports missing/corrupt/divergent dump data

Requirement: Dump validation and iteration must detect missing partition files, wrong hashes, wrong CRC/corrupted payloads, and allow checking from other nodes including empty validation nodes.

Why: Operators need actionable diagnostics before trusting an offline dump.

Boundary: Weaker evidence: corruption is synthetic and some diagnostics depend on exact failure text.

Evidence tests:

DUMP-FAIL-CLEANUP-01 — failed or canceled dump creation fails closed

Requirement: File-create, iterator-write, listener-write, explicit cancel, and unready-dump cases must clean incomplete artifacts and keep the live cache usable.

Why: Failure should not leave misleading artifacts or harm the running cluster.

Boundary: Weaker where cancellation/event evidence is timing-sensitive or wait-result assertions are weak.

Evidence tests:

DUMP-ENCRYPTION-OBS-01 — encrypted, throttled and debug-log dump modes expose operator contracts

Requirement: Encrypted dump creation/reading, dump rate limiting, and DumpReader debug logging must follow tested preconditions and expose group-name/no-group-name log detail.

Why: Operators need secure/controlled dump behavior and useful trace logs for support.

Boundary: Evidence; logging tests prove selected debug messages only.

Evidence tests:

Important boundaries