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)