◼ Apache Ignite Свойства продукта

Apache Ignite 2

Binary marshalling, binary builders и структуры хранения

Публичные свойства продукта, восстановленные по тестовым свидетельствам.

Binary marshalling, binary builders и структуры хранения

Эта страница — публичная реконструкция продуктовой спецификации по исходникам тестов Apache Ignite 2 на ревизии 486a6367610c4c891b729e89373695ef83165345.

Тесты binary mode и структур хранения описывают, как Ignite сохраняет форму объектов, metadata, мутации builder, marshalling identity, сгенерированные serializers сообщений и внутренние свойства упорядоченных индексов, видимые через cache/query behavior.

Пользовательские гарантии

Трассируемые требования

После имени теста указывается только негативный или неоднозначный статус, например status=failed, status=flaky, status=ignored или status=mixed.

BIN-MARSHAL-SCALAR-ROUNDTRIP — binary marshalling сохраняет scalar values

Требование: Ignite binary marshalling сохраняет null, Java primitive wrapper values, UUID/IgniteUuid identifiers, SQL temporal values, и representative UTF-8 strings across marshal/unmarshal.

Зачем это нужно: пользователи полагаются на то, что cache values, messages и metadata-bearing objects проходят binary transport без изменения identity-like values и базовых данных.

Граница: Scalar tests используют representative values, не full domains, locale-sensitive formatting, timezone conversion, or cross-version cluster compatibility. The string tests distinguish legacy и newer UTF-8 behavior but не доказывают каждый некорректный Unicode sequence.

Тесты-доказательства:

BIN-MARSHAL-ARRAY-ROUNDTRIP — binary marshalling сохраняет arrays of primitive values

Требование: Ignite binary marshalling сохраняет arrays of primitive values, common scalar object values, Object arrays, binary-object arrays, и repeated array references inside arrays or object fields.

Зачем это нужно: Distributed cache entries и внутренний messages frequently carry collections of values; array content и repeated references должен survive binary transport для корректный object graphs.

Граница: Тесты покрывают small arrays и выбранные element types. They не establish large-array limits, null elements in каждый array kind, cyclic arrays beyond repeated references, or interoperability between binary-array compatibility modes.

Тесты-доказательства:

BIN-MARSHAL-FIELD-ACCESS — Binary objects раскрывают marshalled fields с their declared value и type

Требование: Binary objects раскрывают marshalled fields с their declared value и type, включая nested objects, SQL temporal fields, decimal fields, и Class fields, при этом deserialization reconstructs equivalent user objects.

Зачем это нужно: Ignite clients и server internals inspect binary fields без full deserialization; field APIs должен match the logical user object.

Граница: The coverage является reflective и marshal-aware decimal classes plus one object с class fields. It не доказывает arbitrary generic class metadata or schema evolution of field types.

Тесты-доказательства:

BIN-MARSHAL-DETACHED-READS — Detached binary reads сохраняют map entries

Требование: Detached binary reads сохраняют map entries, collection members, typed arrays, arrays of collections, и binary collection elements когда binaries являются unwrapped для platform interop.

Зачем это нужно: Platform integrations и binary APIs должен detach nested structures без losing element identity or changing container shape.

Граница: The tests use local marshalling helpers и fixed payload shapes. Они не доказывают cross-language serialization formats, null-heavy collections, ordering для unordered containers, or concurrent access.

Тесты-доказательства:

BIN-MARSHAL-METADATA-EQUALITY — Binary object equality

Требование: Binary object equality, duplicate field naming, и field-order metadata behave deterministically across marshaller configurations, heap/offheap forms, builders, Binarylizable objects, и metadata serialization.

Зачем это нужно: Binary objects являются used as comparable keys, metadata carriers, и schema descriptors; equivalent logical objects должен compare correctly и metadata order/name resolution должен stay предсказуемый.

Граница: testFieldOrder и testFieldOrderByBuilder возвращают early когда sorted-field mode является enabled, so they доказывают insertion/declaration order only для unsorted-field configuration. Duplicate-field checks partly use Java assert, so runtime assertion settings matter для part of the proof.

Тесты-доказательства:

BTREE-SIZE-AND-LOCK-INVARIANTS — B+Tree reports size и filtered size consistently с visible contents во время sequential put/remove operations и lea

Требование: Ignite B+Tree reports size и filtered size consistently с visible contents во время sequential put/remove operations и leaves без page locks после operations.

Зачем это нужно: Storage indexes нужны reliable cardinality и lock cleanup so cache operations, scans, и maintenance code не leak resources or miscount rows.

Граница: Single local test tree only; без persistence restart, real cache index integration, or multi-node topology.

Тесты-доказательства:

BTREE-CONCURRENT-SIZE-BOUNDS — During concurrent put/remove activity

Требование: During concurrent put/remove activity, B+Tree size остается either точные at synchronization points or inside a bounded range когда modification races являются intentionally allowed; the tree validates и releases locks afterward.

Зачем это нужно: Операторы и внутренний components нужны storage metrics и scans that остаются sane при write load без livelock or leaked page locks.

Граница: Это stress-style in-memory tests с timing и CPU-dependent interleavings. They доказывают bounded behavior для configured page capacities и loop counts, не linearizable size при все races.

Тесты-доказательства:

BTREE-CONCURRENT-STRUCTURE-INVARIANTS — B+Tree structural maintenance остается valid при этом puts

Требование: B+Tree structural maintenance остается valid при этом puts, removes, range removes, и iteration-like lookups interleave around split, merge, и empty-leaf edge cases.

Зачем это нужно: Storage indexes должен survive high-churn workloads без leaving unreachable rows, invalid tree shape, or exceptions во время page split/merge races.

Граница: Some checks являются exception/validation based rather than comparing a complete model of contents. Randomized и concurrent scheduling means they являются не exhaustive proofs для каждый tree shape.

Тесты-доказательства:

MSG-CODEGEN-SERIALIZER-SHAPE — Ignite’s message annotation processor generates expected serializer and

Требование: Ignite’s message annotation processor generates expected serializer and, когда needed, marshaller companions для поддержанные Message shapes: simple messages, collections, maps, inherited messages, multiple messages, enum sets, marshallable messages, и JDK-marshalled messages.

Зачем это нужно: Communication message classes depend on generated companions для стабильный wire IO и object marshalling без hand-written boilerplate.

Граница: Golden-source equivalence доказывает generated Java text для fixture classes, не runtime wire compatibility or все possible field type combinations.

Тесты-доказательства:

MSG-CODEGEN-VALIDATION — message processor отвергает неподдержанный or ambiguous message definitions at compile time

Требование: The message processor отвергает неподдержанный or ambiguous message definitions at compile time, включая wrong @Order usage, matrices, POJO fields, Throwable fields, неподдержанный raw/generic shapes, explicit compressed-message internals, invalid compression annotations, и invalid @NioField/@Marshalled combinations.

Зачем это нужно: Failing invalid message schemas во время compilation prevents broken wire protocols и runtime marshalling ошибки.

Граница: Several negative tests assert only ошибка, и some assert диагностический substrings. Они не доказывают complete диагностический stability or каждый неподдержанный Java type.

Тесты-доказательства:

MSG-CODEGEN-ENUM-MAPPERS — Enum mapping annotations являются accepted only для enum fields or nested enum collections/maps

Требование: Enum mapping annotations являются accepted only для enum fields or nested enum collections/maps, one enum field cannot combine incompatible enum types, и a given enum type должен use a согласованный mapper across messages при этом reuse of the same mapper является allowed.

Зачем это нужно: Stable enum wire encoding requires one unambiguous mapper per enum type и clear rejection of mapper annotations that cannot apply.

Граница: Тесты покрывают TransactionIsolation и выбранные fixture structures only. Они не доказывают mapper behavior для каждый enum container nesting pattern.

Тесты-доказательства:

MSG-CODEGEN-MARSHALLED-DEPLOYABLE — processor generates marshaller companions для @Marshalled object

Требование: The processor generates marshaller companions для @Marshalled object, collection, map, и array-backed-map fields, и deployer companions для cache-aware deployable messages включая nested cache messages и custom deployment hooks.

Зачем это нужно: Cache communication messages должен correctly marshal user payloads и deploy binary/cache-object fields using доступный cache context hooks.

Граница: Golden-source comparison checks generated source, не runtime deployment against live caches. The cache context ошибка является one fixture диагностический.

Тесты-доказательства:

MSG-QUERYINDEX-COPY — QueryIndexMessage сохраняет все non-static QueryIndex fields needed чтобы reconstruct an equivalent QueryIndex

Требование: QueryIndexMessage сохраняет все non-static QueryIndex fields needed чтобы reconstruct an equivalent QueryIndex.

Зачем это нужно: Query index definitions должен travel через внутренний cache/query messages без losing index name, indexed fields, type, or inline size.

Граница: Это a shape guard plus one reconstruction case. It не доказывает backward compatibility if QueryIndex gains new non-static fields.

Тесты-доказательства:

A4-BIN-001 — Binary marshalling сохраняет exception диагностика

Требование: When Ignite binary-marshals a Throwable, the deserialized exception должен retain a usable stack trace produced через the Java serialization path.

Зачем это нужно: Пользователи и операторы нужны exceptions stored or transported через Ignite чтобы остаются diagnosable после deserialization.

Граница: Покрывает a simple runtime exception only, не causes, suppressed exceptions, custom exception fields, or cross-version transport.

Тесты-доказательства:

A4-BIN-002 — Binary marshalling round-trips common collection и map implementations

Требование: Ignite binary marshalling должен сохранять equality of standard Java collections/maps и выбранные custom collection implementations с their contents.

Зачем это нужно: Cache values и compute/job payloads commonly embed Java collection types и пользователи expect logical contents чтобы survive round-trip marshalling.

Граница: Покрывает выбранные in-memory collection shapes only; без distributed cache, concurrent mutation, comparator compatibility, or very large collections. testMixedRawCollections only доказывает без exception для two marshaller configurations.

Тесты-доказательства:

A4-BIN-003 — Binary marshalling сохраняет map entries и externalizable/nested values

Требование: Standalone Map.Entry values и externalizable objects nested in enclosing objects должен survive binary marshalling с their key/value or externalized state intact.

Зачем это нужно: User objects may contain map-entry views or externalizable payloads и должен не lose meaning когда cached or transferred.

Граница: Does не доказывают mutable entry aliasing, custom Externalizable ошибка handling, or non-void class metadata generally.

Тесты-доказательства:

A4-BIN-004 — Binary objects раскрывают стабильный field access и deserialize чтобы equivalent reflective/Binarylizable objects

Требование: Binary-marshalled user objects должен раскрывать primitive, scalar, array, enum, collection, map, и nested object fields через BinaryObject.field при этом deserializing back чтобы an equivalent object.

Зачем это нужно: Ignite binary mode lets пользователи inspect выбранные fields без full deserialization и later recover the original object.

Граница: Покрывает local marshalling с configured type metadata и выбранные classes; без schema evolution across releases, cross-language clients, or persistence restart.

Тесты-доказательства:

A4-BIN-005 — Binary object builder can read, set, remove, и rebuild fields без losing object structure

Требование: BinaryObjectBuilder должен сохранять existing data при применении field mutations, включая null assignments, removals, empty-object rebuilds, repeated rebuilds, и cyclic references.

Зачем это нужно: Пользователи полагаются на binary builders для partial updates без deserializing entire objects or corrupting object graphs.

Граница: Покрывает local builder usage only; handle-to-collection equality является asserted rather than identity because the builder не поддерживают preserving the same collection handle.

Тесты-доказательства:

A4-BIN-006 — Binary builder default mappers сохраняют type IDs, hash codes, field values, и metadata для поддержанные field types

Требование: With full-name базовый name/ID mapping и compact footer, binary objects built через the default builder API должен compute configured type IDs, use BinaryArrayIdentityResolver hash semantics, retain поддержанные scalar/array/object/container field values, и publish field metadata.

Зачем это нужно: Пользователям нужны предсказуемый type identity, equality/hash behavior, и field metadata когда building binary objects dynamically.

Граница: Type coverage является broad but local; it не доказывает schema conflict resolution, cross-node metadata propagation, or non-default custom mapper combinations in this builder class.

Тесты-доказательства:

A4-BIN-007 — Binary object copy applies selective field replacements across primitive и object fields

Требование: Копирование BinaryObject через builder должно сохранять unspecified fields и делать supplied replacement fields видимыми как через binary field access, так и после deserialization.

Зачем это нужно: Пользователям нужны reliable partial updates of binary values in cache operations и compute pipelines.

Граница: Does не доказывают rejection of wrong replacement field types; the negative check для invalid type является commented out in source.

Тесты-доказательства:

A4-BIN-008 — Binary marshalling honors custom serializers, custom ID/name mappers, и duplicate identity protections

Требование: Binary marshalling должен применять per-type serializers/mappers ahead of global defaults где configured, use default mapping где custom mappers являются absent, обнаруживают duplicate type IDs or duplicate simple mapped names, и раскрывают registered custom type descriptors consistently.

Зачем это нужно: Пользователям нужны deterministic binary identity и serializer behavior чтобы interoperate across nodes и avoid corrupting metadata.

Граница: Several checks inspect внутренний BinaryContext maps и точные IDs; this является stronger для implementation compatibility than для public API wording. Duplicate-name/type negative tests cover выбранные collision shapes only.

Тесты-доказательства:

A4-BIN-009 — Binary graph marshalling сохраняет object handles, detached objects, read/write replacement, proxy serialization, и offheap equality

Требование: Binary marshalling должен maintain object-graph semantics для cycles, repeated handles, detached binary objects, writeReplace/readResolve, dynamic proxies, cached deserialized values, offheap binary object equality/hash/field access, и thread-local buffer release.

Зачем это нужно: Ignite stores complex object graphs in heap и offheap forms; пользователям нужны identity-sensitive graphs и resource cleanup не чтобы regress.

Граница: Mostly local heap/offheap unit fixtures; без persistence restart, cross-classloader, or remote node transport. testObjectContainingProxy не actually assert a container object field despite the method name.

Тесты-доказательства:

A4-BTREE-001 — B+Tree reports retry exhaustion as a checked ошибка

Требование: The page-memory B+Tree должен выдавать an IgniteCheckedException instead of silently succeeding когда configured retry count является exhausted во время inserts.

Зачем это нужно: Storage operations должен не hide structural access ошибки; callers нужны a checked ошибка they can handle.

Граница: Does не assert the exception message or точные retry counter behavior.

Тесты-доказательства:

A4-BTREE-002 — B+Tree maintains search, removal, size, root-level, и page-lock invariants across insert/remove order matrices

Требование: The page-memory B+Tree должен поддерживать ordered put/remove sequences при small page capacities и varied put/remove directions, включая range removals, при этом keeping lookup results, empty-tree size/root-level, structural validation, и page-lock cleanup корректный.

Зачем это нужно: Cache indexes depend on B+Tree structural invariants regardless of insertion/removal order or small-page split/merge pressure.

Граница: Только internal test tree; не доказывает real cache/index integration, crash recovery, or persistence restart.

Тесты-доказательства:

A4-BTREE-003 — B+Tree invoke/put/remove randomized operations сохраняют map-equivalent contents

Требование: The B+Tree invoke, put, и remove operations должен оставаться equivalent чтобы a reference map при randomized local operation streams при этом preserving structural validity и releasing page locks.

Зачем это нужно: Index operations combine conditional updates и removes; data loss or duplicate keys would corrupt query/index behavior.

Граница: Uses generated randomness и periodic content checks; без deterministic coverage of все operation orders.

Тесты-доказательства:

A4-BTREE-004 — B+Tree обрабатывает massive concurrent put/remove batches без structural corruption

Требование: Under multithreaded insert и removal pressure, B+Tree должен end с expected size и ordered contents, validate structure, и не leak page locks.

Зачем это нужно: Concurrent index maintenance должен оставаться согласованный во время high write/remove pressure.

Граница: Stress-style local fixture с fixed key counts и page capacities; без transactional or persistence guarantees.

Тесты-доказательства:

A4-BTREE-005 — B+Tree поддерживает concurrent randomized put/remove/invoke plus range scans

Требование: During concurrent put/remove/invoke operations, B+Tree range cursors должен возвращают keys within bounds in strictly increasing order с без duplicates, и final tree contents/size должен match the reference map.

Зачем это нужно: Query/index scans должен оставаться ordered и согласованный при этом writes являются happening.

Граница: Uses per-key striped test locks для writes и stress timing; не доказывает все production concurrency interleavings.

Тесты-доказательства:

Важные границы