You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bruce Schuchardt (JIRA)" <ji...@apache.org> on 2018/04/05 21:45:00 UTC

[jira] [Created] (GEODE-5019) Bullet-proof deserialization of reply messages

Bruce Schuchardt created GEODE-5019:
---------------------------------------

             Summary: Bullet-proof deserialization of reply messages
                 Key: GEODE-5019
                 URL: https://issues.apache.org/jira/browse/GEODE-5019
             Project: Geode
          Issue Type: Improvement
            Reporter: Bruce Schuchardt


If a ReplyMessage (or any other sort of response message) fails to deserialize we currently log the problem and forget about it.  This can leave the thread waiting for a response hung.

We should do something like we have in place on the request-message side where the message registers its "reply processor id" in a thread-local that TcpConduit can then find and use to send an error response if deserialization of the request fails.

I think we could just use this same logic but maybe a different thread-local so that we know it's a reply instead of a request that's being deserialized.  In that case we could grab the reply processor id and look for the corresponding processor & notify it of the problem so it can stop waiting for that sender.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)