[jira] [Updated] (GEODE-6624) SIGABRT Due to nested exceptions when value returned that can't be deserialized

["Diane Hardman (Jira)" <ji...@apache.org>]

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

Diane Hardman updated GEODE-6624:
---------------------------------
    Fix Version/s: 1.10.0

> SIGABRT Due to nested exceptions when value returned that can't be deserialized
> -------------------------------------------------------------------------------
>
>                 Key: GEODE-6624
>                 URL: https://issues.apache.org/jira/browse/GEODE-6624
>             Project: Geode
>          Issue Type: Bug
>          Components: native client
>            Reporter: Blake Bender
>            Priority: Major
>             Fix For: 1.10.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> This gets a little weird, but in a nutshell:
>  * a client app needs to deploy a jar file containing a custom DataSerializable object _without_ a default constructor, and a server function that returns a value of this type
>  * Then, the app needs to call execute on a function service on a region (or maybe a server, we're not sure it's relevant) to call the function that returns the value of the class that's missing the default dtor
>  * In response, the server will send back a payload with dscode=45 (DataSerializable), then a byte field for the type, which will be set to dscode 43 (Class), then a string which is the name of the class, then the bytes resulting from a call to toData() on that class instance
>  * The native client cannot correctly interpret this message, so the worker thread that is trying to decode the message stores an exception to throw later.
>  * Later on in the main thread, an exception gets thrown in TcrMessage::readMessageChunked, but on the way out of readMessageChunked the dtor for the contained FinalizeProcessChunk object gets called, which calls m_reply.processChunk, which _also_ throws an exception, at which point the process aborts because of the nested exceptions
> We need to eat the 2nd exception, and throw the 1st, so that client apps can catch the exception _and_ get an accurate message about what went wrong.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)