Anton Vinogradov created IGNITE-28950:
-----------------------------------------
Summary: Unmarshal failure on the regular receive path is silent
Key: IGNITE-28950
URL: https://issues.apache.org/jira/browse/IGNITE-28950
Project: Ignite
Issue Type: Improvement
Reporter: Anton Vinogradov
{{GridIoManager#processRegularMessage0}} calls {{unmarshalPayload}}, which
wraps a failure into an unchecked {{IgniteException}} and throws it. Nothing in
that method catches it, so a message whose payload cannot be unmarshalled can
disappear with nothing written to the log.
The ordered path does the opposite, on purpose:
{code:java}
catch (IgniteException e) {
// Skip the failed message: rethrowing would abandon the rest of the set
until
// the next message arrives on this topic.
U.error(log, "Failed to unmarshal ordered message (will skip) [nodeId=" +
nodeId +
", msg=" + mc.message + ']', e);
continue;
}
{code}
So the same failure is handled deliberately in {{OrderedMessageSet#unwind}} and
not at all in the regular path.
For a request/response protocol the effect is worse than a lost message: the
sender waits for an answer that will never come, so the symptom is a hang and
not an error. This showed up while working on IGNITE-28901 - removing
{{DeferredUnmarshalMessage}} from the event query request made
{{GridP2PTimeoutSelfTest}} hang forever with nothing in the log to explain it.
h3. What to do
Log the failure on the regular path the way the ordered path already does. That
alone turns a silent hang into something a user can diagnose.
Telling the sender is a separate and harder question: the generic pass does not
know the protocol of the message it carries - which topic to answer to, what
the response type is - which is exactly why {{DeferredUnmarshalMessage}}
exists. Its javadoc names "a protocol-level failure response to the sender" as
one of the three things deferral buys.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
