[
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)
