valepakh commented on PR #7914:
URL: https://github.com/apache/ignite-3/pull/7914#issuecomment-4188743714
> **MessageImplGenerator: field ordering change in hashCode**
Why it's safe despite the change
1. hashCode is NEVER serialized over the wire. Generated message
serializers only write field values (writer.writeInt, writer.writeString,
etc.). The hashCode value itself is never transmitted.
2. hashCode is NEVER persisted to disk. Not in raft logs, raft snapshots,
metastorage, or catalog storage. Raft commands are stored as serialized byte
buffers containing only field data.
3. Maps/Sets with message keys are fully reconstructed on deserialization.
DirectByteBufferStreamImplV1.readMap() creates a new HashMap and inserts
deserialized entries using map.put() — which computes hashCode locally on the
receiver. The sender's hash bucket layout is not preserved.
4. No cross-node hashCode agreement is needed. No protocol compares
hashCode values between nodes. Message routing uses groupType() and
messageType() (short integer IDs), not hashCode.
5. Rolling upgrades are safe. Even if an old node sends a
NodesLeaveCommand with Set<ClusterNodeMessage> to a new node via raft:
- The Set is serialized as individual elements (field data only)
- The receiving node deserializes each element and inserts into a new
local HashSet using its own hashCode
- The logical content is identical regardless of hash values
6. No deterministic iteration dependency. No code relies on
HashMap/HashSet iteration order of message collections. Java makes no such
guarantee anyway.
The only theoretical risk
If some code path iterated over a Set<ClusterNodeMessage> and the
iteration order happened to matter (e.g., producing deterministic output for
comparison), the changed hashCode could alter iteration order. However, no such
usage exists in the codebase — NodesLeaveCommand.nodes() is iterated to
remove nodes from the logical topology, and order doesn't matter there
(CmgRaftGroupListener line 316 streams and collects to a new set).
Conclusion
It is safe to change the hashCode field ordering for network messages.
PakhomovAlexander's analysis of the behavioral change is technically correct —
the hash values do change for messages with mixed field types — but it has
no observable impact because hashCode is purely a JVM-local concern for
these messages, never crossing serialization or process boundaries.
--
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]
