[
https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489813#comment-17489813
]
Mario Salazar de Torres edited comment on GEODE-10029 at 2/9/22, 9:07 PM:
--------------------------------------------------------------------------
Hi [~echobravo],
Sorry, I should have added some context for why I chose to open this ticket as
a bug and not a feature.
Thing is that we are noticing an issue under the following scenario:
# From a native client, I create an object using a PdxSerializable
implementation, which has an String field.
# After that, we are reading this object from a java client which cache has
readPdxSerialized=true and comparing it with a PdxInstance created locally
inside the Java client.
# As PdxInstanceImpl.equals method uses rawBytes for strings, if the string is
serialized using different DSCodes, the comparison will fail, even if the
length and content are the same.
*Note that* as stated by the ticket description, whenever writing an ASCII
string inside the native client it's DSCode will be CacheableString, whenever
in the case of the Java client will actually be CacheableASCIIString.
That's why there are 3 approaches here:
* Modify the native client so whenever writeString is called, the string is
parsed and the DSCode is selected depending on wether it contains an UTF-8
string or just an ASCII string, just like Java client is doing right now.
* Modify PdxInstanceImpl equals method, so the DSCode is not taken into
account whenever comparing string fields.
* Both of the above.
So I'd say, given this information, it's indeed a bug. If you don't see it that
way, I don't have any issue in re-opening it as an improvement. I'll push the
PR eitherways.
was (Author: gaussianrecurrence):
Hi [~echobravo],
Sorry, I might have added some context for why I chose to open this ticket as a
bug and not a feature.
Thing is that we are noticing an issue under the following scenario:
# From a native client, I create an object using a PdxSerializable
implementation, which has an String field.
# After that, we are reading this object from a java client which cache has
readPdxSerialized=true and comparing it with a PdxInstance created locally
inside the Java client.
# As PdxInstanceImpl.equals method uses rawBytes for strings, if the string is
serialized using different DSCodes, the comparison will fail, even if the
length and content are the same.
*Note that* as stated by the ticket description, whenever writing an ASCII
string inside the native client it's DSCode will be CacheableString, whenever
in the case of the Java client will actually be CacheableASCIIString.
That's why there are 3 approaches here:
* Modify the native client so whenever writeString is called, the string is
parsed and the DSCode is selected depending on wether it contains an UTF-8
string or just an ASCII string, just like Java client is doing right now.
* Modify PdxInstanceImpl equals method, so the DSCode is not taken into
account whenever comparing string fields.
* Both of the above.
So I'd say, given this information, it's indeed a bug. If you don't see it that
way, I don't have any issue in re-opening it as an improvement. I'll push the
PR eitherways.
> Strings are not correctly serialized
> ------------------------------------
>
> Key: GEODE-10029
> URL: https://issues.apache.org/jira/browse/GEODE-10029
> Project: Geode
> Issue Type: Bug
> Components: native client
> Reporter: Mario Salazar de Torres
> Priority: Major
> Labels: needsTriage
>
> *GIVEN* a PdxSerializable implementation with a string field
> *WHEN* an ASCII string is written
> *THEN* the string is serialized with the DSCode CacheableString
> ----
> *Additional information.* In the Java client, whenever writing an string, the
> string is parsed and the DSCode is assigned depending on the string
> codification. In the native client, it's always set to CacheableString,
> whenever for example in the case of an ASCII string should be
> CacheableASCIIString
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
