Roman Puchkovskiy created IGNITE-18072:
------------------------------------------
Summary: Help diagnose situations when a sender sends an
incomplete message
Key: IGNITE-18072
URL: https://issues.apache.org/jira/browse/IGNITE-18072
Project: Ignite
Issue Type: Improvement
Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
Fix For: 3.0.0-beta2
The following scenario is possible.
# Due to a misconfiguration, some required serializer is not registered
# A message starts to be written, namely its groupId and messageTypeId are
written
# Now we try to write the message (probably we write some part of it), but
this fails with an exception due to a missing serializer. So the message is
only partly written
# Next message is written successfully
# The receiver tries to read first message. It has no idea that only part of
it is written, so it also consumes the beginning of the next message. The first
message is read incorrectly, but we don't know this yet
# The receiver tries to read second message (starting somewhere in the middle
of its bytes). This usually causes an assertion of an exception due to a
missing groupId/messageTypeId, or, if we have (bad) luck, this can lead to
reading a wrong message (that was never sent)
# Sooner or later, an exception happens on the receiving side, but its message
will be misleading
This might make diagnosing 'what happened' by looking at the receiver's logs
problematic. We could add an additional step: before writing the message
groupId+messageTypeId, visit the message (including its parts) and check that
all serializers are registered. If not, write some special marker (like short
-1) followed by groupId+messageTypeId and nothing more for this message (then
throw an exception). The receiving side will be able to interpret this as 'no
serializer' situation and log an appropriate diagnostic message before throing
an exception.
This situation mostly happens at development time, so we could only enable this
additional screening step when we are in the development mode (for example,
when assertions are enabled).
This could also relate to rolling upgrades.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
