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

["Bruce Schuchardt (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Schuchardt updated GEODE-5019:
------------------------------------
    Component/s: messaging

> Bullet-proof deserialization of reply messages
> ----------------------------------------------
>
>                 Key: GEODE-5019
>                 URL: https://issues.apache.org/jira/browse/GEODE-5019
>             Project: Geode
>          Issue Type: Improvement
>          Components: messaging
>            Reporter: Bruce Schuchardt
>            Priority: Major
>
> 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)