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

Reply via email to