geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-4168) Can't get json object stored as PDX using the new protocol
Date Tue, 02 Jan 2018 19:50:02 GMT


ASF subversion and git services commented on GEODE-4168:

Commit d0a6394d318aa486f50264e90a834dc8ccf76303 in geode's branch refs/heads/develop from
[;h=d0a6394 ]

GEODE-4168 Can't get json object stored as PDX using the new protocol
GEODE-4116 Can't get PDX objects using the new protocol

Added a distributed test to ensure end-to-end handling of JSON documents
is functioning correctly.  For GEODE-4168 I changed the class-check from
equals() to isAssignableFrom().  For GEODE-4116 I modified the Get and
GetAll operation handlers to inhibit deserialization of PdxInstances
when reading values from the cache.  The test for 4116 ensures that
the value is in serialized form by putting it into a distributed Region
in another JVM.

There are unrelated javadoc changes in this commit for and
a couple of classes in the protobuf Driver module.  I also added
constraints to the Regions in the Driver's unit test to get rid of
compilation warnings.

This closes #1209

> Can't get json object stored as PDX using the new protocol
> ----------------------------------------------------------
>                 Key: GEODE-4168
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: client/server
>            Reporter: Dan Smith
> When trying to do a get for an json object using the new client protocol, users now receive
this exception
> {noformat}
> [error 2017/12/25 12:05:12.985 PST server1 <ServerConnection on port 40404 Thread
15> tid=0x83] Received Get request with unsupported encoding: {}
> org.apache.geode.internal.protocol.serialization.exception.EncodingException: No protobuf
encoding for type org.apache.geode.pdx.internal.PdxInstanceImpl
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufSerializationService.encode(
>        at org.apache.geode.internal.protocol.protobuf.v1.operations.GetRequestOperationHandler.process(
>        at org.apache.geode.internal.protocol.protobuf.v1.operations.GetRequestOperationHandler.process(
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufOpsProcessor.processOperation(
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufOpsProcessor.process(
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufStreamProcessor.processOneMessage(
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufStreamProcessor.receiveMessage(
>        at org.apache.geode.internal.protocol.protobuf.v1.ProtobufCachePipeline.processMessage(
>        at org.apache.geode.internal.cache.tier.sockets.GenericProtocolServerConnection.doOneMessage(
>        at
> {noformat}
> This looks like a bug introduced by e24e038e69244cc655779634945896411e678080. ProtobufEncodingTypes.valueOf
is trying to do a Class.equals between PdxInstance and PdxIntanceImpl.
> This is somewhat related to GEODE-4116 in that it's another failure to get a pdx serialized
value, but the underlying cause is different in this case.

This message was sent by Atlassian JIRA

View raw message