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)
