IGNITE-28520 Auto-generate message serialization / marshalling / deployment#13095
IGNITE-28520 Auto-generate message serialization / marshalling / deployment#13095anton-vinogradov wants to merge 320 commits into
Conversation
cb7ec5a to
802f7e1
Compare
|
| Map<Class<?>, Short> REGISTRATIONS = new ConcurrentHashMap<>(); | ||
|
|
||
| /** Per-class cache over {@link #REGISTRATIONS}; keeps {@link #directType()} off the map lookup done for every sent message. */ | ||
| ClassValue<Short> DIRECT_TYPES = new ClassValue<>() { |
There was a problem hiding this comment.
Why changed? let's use just REGISTRATIONS.
There was a problem hiding this comment.
The ClassValue isn't a rename, it's a cache with a contract: a plain REGISTRATIONS.get(getClass()) returns null for an unregistered class → NPE on unboxing, while DIRECT_TYPES throws UnknownMessageException, which production discovery (TcpDiscoverySpi, ServerImpl, TcpDiscoveryIoSession) catches for unknown-type tolerance and DiscoverySerializationExceptionTest covers.
| import org.apache.ignite.plugin.extensions.communication.MessageWriter; | ||
|
|
||
| /** Serializer for {@link TestDelayMessage} that injects an optional write delay for testing. */ | ||
| public class TestDelayMessageSerializer implements MessageSerializer<TestDelayMessage> { |
There was a problem hiding this comment.
It's resolved by naming convention: MessagesPluginProvider registers TestDelayMessage with GridTestUtils.loadSerializer(msg), which loads this class. Codegen intentionally skips the message (SKIP_MESSAGES in MessageProcessor) because the hand-written serializer injects a write delay a generated one can't.
# Conflicts: # modules/codegen/src/main/java/org/apache/ignite/internal/MessageSerializerGenerator.java # modules/codegen/src/main/java/org/apache/ignite/internal/idto/IDTOSerializerGenerator.java # modules/zookeeper/src/main/java/org/apache/ignite/spi/discovery/zk/internal/ZkMessageFactory.java # modules/zookeeper/src/main/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoveryImpl.java
|
/runall |
Possible compatibility issues. Please, check rolling upgrade casesThis PR modifies protected classes (with Order annotation). Affected files:
|
|
Ignite PR Checker verdict · RunAll build 9216359 · 147 suites ran, 0 reused
🔍 2 suite(s) ran fewer tests than on master (tests that never ran can't fail):
✅ No test blockers otherwise; 26 pre-existing/flaky filtered out. ♻️ Settled after 2 auto re-run wave(s): #1 — 2 broken suite(s); #2 — 1 broken suite(s). |




What
Extends the annotation-driven message codegen (previously serialization-only) to
marshalling and deployment: a message's wire read/write, marshalling and
deployment are now generated from declarative field annotations, replacing
hand-written writeTo/readFrom, prepareMarshal/finishUnmarshal and prepareDeployment.
Main directions
Generated marshaller & deployer companions.
MessageProcessornow emits<Msg>Marshallerand<Msg>Deployernext to<Msg>Serializer, driven by@Marshalled/@MarshalledCollection/@MarshalledMap(with@Order/@NioField). Hand-written marshalling/deployment hooks are removed from messages.Uniform factory dispatch.
MessageFactoryresolves all three by direct type —serializer()/marshaller()/deployer()— via oneregister(directType, supplier, serializer, marshaller, deployer). Callers use thestatic facades
MessageSerializer.writeTo/readFrom,MessageMarshaller.marshal/unmarshal,GridCacheMessageDeployer.deploy; an ArchUnit rule (MessageSerializationArchitectureTest)enforces it.
Comm & discovery wired to it.
GridIoManager/GridCacheIoManager/IgniteTxManagerand the TCP/ZK discovery I/O callMessageMarshaller.marshal/unmarshal;discovery custom messages (
MetadataUpdateProposedMessage,BinaryMetadataVersionInfo, …)move from
MarshallableMessagehooks to@Marshalled.Deployment collapsed.
GridCacheMessageDeployeris now only the codegen interfaceplus the factory-resolving facade; per-field static bridges dropped,
GridCacheMessage#deploy*accessed directly.
Marshalling stays off the NIO threads. The NIO codec does only serialization
(
writeTo/readFrom); the actual marshal/unmarshal runs on the sender and workerthreads.
@NioField+unmarshalNioare the explicit, minimal exception — only thehandful of fields needed for early dispatch are unmarshalled on the NIO thread.
Side effects (mechanical — skim)
prepareMarshal→marshal,finishUnmarshal→unmarshal,finishUnmarshalNio→unmarshalNio(onMarshallableMessage/MessageMarshaller);CacheObject#prepareMarshal(ctx)/finishUnmarshal(ctx)→marshal/unmarshal;prepareDeployment+prepare*Deploymenthelpers →deploy/deploy*;MarshallerCacheFreeFinishTest→…UnmarshalTest,MessageFinishUnmarshalOnceTest→MessageUnmarshalOnceTest..mvn/jvm.configopensjdk.compilerfor the codegen tests(Google compile-testing);
commit-check.ymlnow surfaces the real compile errorbehind the generated-class "cannot find symbol" cascade.
Performance
JMH-verified: serialization hot path unchanged (Δ ≈ 0 vs master); marshalling adds
~1.8 ns/message of factory dispatch (<0.5% of the actual
U.marshal, ~µs); zero extraallocations.