anton-vinogradov commented on code in PR #13095:
URL: https://github.com/apache/ignite/pull/13095#discussion_r3559629102
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/binary/MetadataUpdateProposedMessage.java:
##########
@@ -184,25 +183,17 @@ public BinaryMetadata metadata() {
/** @param metadata Metadata. */
public void metadata(BinaryMetadata metadata) {
this.metadata = metadata;
+
+ // Invalidate the cached marshalled form so a re-marshal (e.g.
coordinator re-propagating merged metadata)
+ // picks up the new value instead of keeping the stale bytes under the
marshal-once guard.
+ this.metadataBytes = null;
Review Comment:
Agreed — dropped. It was a stopgap for a real staleness issue (coordinator
merges metadata into a received instance, and the marshal-once guard would
re-send the pre-merge bytes), but the generated `unmarshal` now nulls the
companion bytes right after decode (added for heap relief), which closes the
same hole at a single choke point for every message. On the sending side the
mutation is ordered before the first marshal (`ServerImpl` awaits the
mutable-message notification before forwarding), so the cached bytes can't go
stale there either. Verified with the multinode metadata-exchange test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
