[
https://issues.apache.org/jira/browse/GEODE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-6699:
--------------------------------
Description:
A Native Client customer reported a crash when running code like this (See
GEODE-6624), and when the NC crash was fixed we discovered that the request
timed out, rather than throwing an exception right away as expected. What
happens is more-or-less as follows:
* start a locator and two servers
* deploy a function to Geode that returns an instance of a class that the
server can't deserialize because it doesn't have a default constructor
* Run an app that uses the native client to execute the function on a region
Expected result:
* Server returns a chunked message containing one value, with the type field
set to DataSerializable and the subtype to 'Class', followed by the string name
of the class and the buffer resulting from a call to toData on said instance
* Native client reads the result and immediately throws a
FunctionExecutionException
Actual result:
* Server returns a chunked message containing one value, with the type field
set to DataSerializable and the subtype to 'Class', followed by the string name
of the class and the buffer resulting from a call to toData on said instance,
BUT... the 'lastChunk' field of the reply is set to 0, i.e. this is not the
last chunk
* Native Client chunk processor sees that reply is not the last chunk, and
asks the server for the next chunk
* Server does not return any more chunks, and client request times out
* Native Client throws NotConnectedException in response to the timed-out
request
Repro steps:
* Clone Native Client
* In the file cppcache/integration/test/FunctionExecutionTest.cpp, test case
FunctionReturnsObjectWhichCantBeDeserializedOnServer, change the type of
exception asserted from NotConnectedException to DeserializationException
* Build Native Client
* Run the test case FunctionReturnsObjectWhichCantBeDeserializedOnServer in
the FunctionExecutionTests suite
was:
A Native Client customer reported a crash when running code like this (See
GEODE-6624), and when the NC crash was fixed we discovered that the request
timed out, rather than throwing an exception right away as expected. What
happens is more-or-less as follows:
* start a locator and two servers
* deploy a function to Geode that returns an instance of a class that the
server can't deserialize because it doesn't have a default constructor
* Run an app that uses the native client to execute the function on a region
Expected result:
* Server returns a chunked message containing one value, with the type field
set to DataSerializable and the subtype to 'Class', followed by the string name
of the class and the buffer resulting from a call to toData on said instance
* Native client reads the result and immediately throws a
FunctionExecutionException
Actual result:
* Server returns a chunked message containing one value, with the type field
set to DataSerializable and the subtype to 'Class', followed by the string name
of the class and the buffer resulting from a call to toData on said instance,
BUT... the 'lastChunk' field of the reply is set to 0, i.e. this is not the
last chunk
* Native Client chunk processor sees that reply is not the last chunk, and
asks the server for the next chunk
* Server does not return any more chunks, and client request times out
* Native Client throws NotConnectedException in response to the timed-out
request
Repro steps:
* Build Native Client
* Run the test case FunctionReturnsObjectWhichCantBeDeserializedOnServer in
the FunctionExecutionTests suite
> Server returns incorrect chunked response in the presence of an object it
> can't deserializa
> -------------------------------------------------------------------------------------------
>
> Key: GEODE-6699
> URL: https://issues.apache.org/jira/browse/GEODE-6699
> Project: Geode
> Issue Type: Bug
> Components: core
> Reporter: Blake Bender
> Priority: Major
>
> A Native Client customer reported a crash when running code like this (See
> GEODE-6624), and when the NC crash was fixed we discovered that the request
> timed out, rather than throwing an exception right away as expected. What
> happens is more-or-less as follows:
> * start a locator and two servers
> * deploy a function to Geode that returns an instance of a class that the
> server can't deserialize because it doesn't have a default constructor
> * Run an app that uses the native client to execute the function on a region
> Expected result:
> * Server returns a chunked message containing one value, with the type field
> set to DataSerializable and the subtype to 'Class', followed by the string
> name of the class and the buffer resulting from a call to toData on said
> instance
> * Native client reads the result and immediately throws a
> FunctionExecutionException
> Actual result:
> * Server returns a chunked message containing one value, with the type field
> set to DataSerializable and the subtype to 'Class', followed by the string
> name of the class and the buffer resulting from a call to toData on said
> instance, BUT... the 'lastChunk' field of the reply is set to 0, i.e. this is
> not the last chunk
> * Native Client chunk processor sees that reply is not the last chunk, and
> asks the server for the next chunk
> * Server does not return any more chunks, and client request times out
> * Native Client throws NotConnectedException in response to the timed-out
> request
> Repro steps:
> * Clone Native Client
> * In the file cppcache/integration/test/FunctionExecutionTest.cpp, test case
> FunctionReturnsObjectWhichCantBeDeserializedOnServer, change the type of
> exception asserted from NotConnectedException to DeserializationException
> * Build Native Client
> * Run the test case FunctionReturnsObjectWhichCantBeDeserializedOnServer in
> the FunctionExecutionTests suite
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
