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

["Blake Bender (JIRA)" <ji...@apache.org>]

Blake Bender created GEODE-6624:
-----------------------------------

             Summary: 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


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
(v7.6.3#76005)