[
https://issues.apache.org/jira/browse/IGNITE-18072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18072:
----------------------------------------
Fix Version/s: 3.2
(was: 3.1)
> 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
> Priority: Major
> Labels: ignite-3
> Fix For: 3.2
>
>
> 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)
