[jira] [Closed] (GEODE-10429) Setup up GH actions as CI solution
[ https://issues.apache.org/jira/browse/GEODE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-10429. --- > Setup up GH actions as CI solution > -- > > Key: GEODE-10429 > URL: https://issues.apache.org/jira/browse/GEODE-10429 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* geode-native contributor > *I WANT TO* setup the CI solution within GH actions > *SO THAT* contributions can be verified -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10429) Setup up GH actions as CI solution
[ https://issues.apache.org/jira/browse/GEODE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-10429. - Resolution: Won't Fix > Setup up GH actions as CI solution > -- > > Key: GEODE-10429 > URL: https://issues.apache.org/jira/browse/GEODE-10429 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* geode-native contributor > *I WANT TO* setup the CI solution within GH actions > *SO THAT* contributions can be verified -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10429) Setup up GH actions as CI solution
[ https://issues.apache.org/jira/browse/GEODE-10429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10429: --- Assignee: Mario Salazar de Torres > Setup up GH actions as CI solution > -- > > Key: GEODE-10429 > URL: https://issues.apache.org/jira/browse/GEODE-10429 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* geode-native contributor > *I WANT TO* setup the CI solution within GH actions > *SO THAT* contributions can be verified -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10429) Setup up GH actions as CI solution
Mario Salazar de Torres created GEODE-10429: --- Summary: Setup up GH actions as CI solution Key: GEODE-10429 URL: https://issues.apache.org/jira/browse/GEODE-10429 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *AS A* geode-native contributor *I WANT TO* setup the CI solution within GH actions *SO THAT* contributions can be verified -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10426) Make documentation generation optional
[ https://issues.apache.org/jira/browse/GEODE-10426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-10426. --- > Make documentation generation optional > -- > > Key: GEODE-10426 > URL: https://issues.apache.org/jira/browse/GEODE-10426 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.16.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* native client contributor > *I WANT TO* have documentation conditionally generated > *AND* be generated by default > *SO THAT* compilation time is reduced > *AND* users do not need doxygen as dependency just to compile the library -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10426) Make documentation generation optional
[ https://issues.apache.org/jira/browse/GEODE-10426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-10426. - Resolution: Fixed > Make documentation generation optional > -- > > Key: GEODE-10426 > URL: https://issues.apache.org/jira/browse/GEODE-10426 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.16.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* native client contributor > *I WANT TO* have documentation conditionally generated > *AND* be generated by default > *SO THAT* compilation time is reduced > *AND* users do not need doxygen as dependency just to compile the library -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10426) Make documentation generation optional
[ https://issues.apache.org/jira/browse/GEODE-10426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10426: --- Assignee: Mario Salazar de Torres > Make documentation generation optional > -- > > Key: GEODE-10426 > URL: https://issues.apache.org/jira/browse/GEODE-10426 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.16.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* native client contributor > *I WANT TO* have documentation conditionally generated > *AND* be generated by default > *SO THAT* compilation time is reduced > *AND* users do not need doxygen as dependency just to compile the library -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10426) Make documentation generation optional
Mario Salazar de Torres created GEODE-10426: --- Summary: Make documentation generation optional Key: GEODE-10426 URL: https://issues.apache.org/jira/browse/GEODE-10426 Project: Geode Issue Type: Improvement Components: native client Affects Versions: 1.16.0 Reporter: Mario Salazar de Torres *AS A* native client contributor *I WANT TO* have documentation conditionally generated *AND* be generated by default *SO THAT* compilation time is reduced *AND* users do not need doxygen as dependency just to compile the library -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10414) Add putIfAbsent method to region interfaces
[ https://issues.apache.org/jira/browse/GEODE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10414: --- Assignee: Mario Salazar de Torres > Add putIfAbsent method to region interfaces > --- > > Key: GEODE-10414 > URL: https://issues.apache.org/jira/browse/GEODE-10414 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* geode-native contributor > *I WANT TO* have putIfAbsent region method implemented > *SO THAT* I can atomically put entries only if they don't previously, exist > and also, to align it with the Java API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10414) Add putIfAbsent method to region interfaces
Mario Salazar de Torres created GEODE-10414: --- Summary: Add putIfAbsent method to region interfaces Key: GEODE-10414 URL: https://issues.apache.org/jira/browse/GEODE-10414 Project: Geode Issue Type: New Feature Components: native client Reporter: Mario Salazar de Torres *AS A* geode-native contributor *I WANT TO* have putIfAbsent region method implemented *SO THAT* I can atomically put entries only if they don't previously, exist and also, to align it with the Java API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10404) Fix compilation for Java 11
[
https://issues.apache.org/jira/browse/GEODE-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-10404:
Description:
It seems that after merging
[#973|https://github.com/apache/geode-native/pull/973], compilation with Geode
Native Docker build image for version 1.15.0 is broken. This is the compilation
error:
{noformat}
tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
character (0xAC) for encoding US-ASCII
pdxInstanceFactory.writeString("utfHugeField", longString + "???");
{noformat}
As it seems, the latest docker image is using Java 11, which handles UTF-8
strings in a different way to Java 8, so that's why compilation is working with
packer images and not with Docker build image.
was:
It seems that after merging #973, compilation with Geode Native Docker build
image for version 1.15.0 is broken. This is the compilation error:
{noformat}
tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
character (0xAC) for encoding US-ASCII
pdxInstanceFactory.writeString("utfHugeField", longString + "???");
{noformat}
As it seems, the latest docker image is using Java 11, which handles UTF-8
strings in a different way to Java 8, so that's why compilation is working with
packer images and not with Docker build image.
> Fix compilation for Java 11
> ---
>
> Key: GEODE-10404
> URL: https://issues.apache.org/jira/browse/GEODE-10404
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> It seems that after merging
> [#973|https://github.com/apache/geode-native/pull/973], compilation with
> Geode Native Docker build image for version 1.15.0 is broken. This is the
> compilation error:
> {noformat}
> tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
> character (0xAC) for encoding US-ASCII
> pdxInstanceFactory.writeString("utfHugeField", longString + "???");
> {noformat}
> As it seems, the latest docker image is using Java 11, which handles UTF-8
> strings in a different way to Java 8, so that's why compilation is working
> with packer images and not with Docker build image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GEODE-10404) Fix compilation for Java 11
Mario Salazar de Torres created GEODE-10404:
---
Summary: Fix compilation for Java 11
Key: GEODE-10404
URL: https://issues.apache.org/jira/browse/GEODE-10404
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Mario Salazar de Torres
It seems that after merging #973, compilation with Geode Native Docker build
image for version 1.15.0 is broken. This is the compilation error:
{noformat}
tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
character (0xAC) for encoding US-ASCII
pdxInstanceFactory.writeString("utfHugeField", longString + "???");
{noformat}
As it seems, the latest docker image is using Java 11, which handles UTF-8
strings in a different way to Java 8, so that's why compilation is working with
packer images and not with Docker build image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-10404) Fix compilation for Java 11
[
https://issues.apache.org/jira/browse/GEODE-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-10404:
---
Assignee: Mario Salazar de Torres
> Fix compilation for Java 11
> ---
>
> Key: GEODE-10404
> URL: https://issues.apache.org/jira/browse/GEODE-10404
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> It seems that after merging #973, compilation with Geode Native Docker build
> image for version 1.15.0 is broken. This is the compilation error:
> {noformat}
> tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
> character (0xAC) for encoding US-ASCII
> pdxInstanceFactory.writeString("utfHugeField", longString + "???");
> {noformat}
> As it seems, the latest docker image is using Java 11, which handles UTF-8
> strings in a different way to Java 8, so that's why compilation is working
> with packer images and not with Docker build image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-10402) Fix FunctionException handling
[ https://issues.apache.org/jira/browse/GEODE-10402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10402: --- Assignee: Mario Salazar de Torres > Fix FunctionException handling > -- > > Key: GEODE-10402 > URL: https://issues.apache.org/jira/browse/GEODE-10402 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a ServerFunction throwing a FunctionException > *WHEN* its executed > *THEN* a CacheServerException is thrown rather FunctionException > > *Additional info.* FunctionException seems not to be handled, that's why the > default handling exception is thrown by the native API, CacheServerException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10402) Fix FunctionException handling
Mario Salazar de Torres created GEODE-10402: --- Summary: Fix FunctionException handling Key: GEODE-10402 URL: https://issues.apache.org/jira/browse/GEODE-10402 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a ServerFunction throwing a FunctionException *WHEN* its executed *THEN* a CacheServerException is thrown rather FunctionException *Additional info.* FunctionException seems not to be handled, that's why the default handling exception is thrown by the native API, CacheServerException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10400) Function execution triggering internal exception
[ https://issues.apache.org/jira/browse/GEODE-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10400: --- Assignee: Mario Salazar de Torres > Function execution triggering internal exception > > > Key: GEODE-10400 > URL: https://issues.apache.org/jira/browse/GEODE-10400 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a cluster with at least 3 members > *AND* a partitioned region with 1 redundant-copy > *AND* a server function called *JustAFunction* with isHA=false, > hasResult=true, optimizeForWrite=true > *AND* a native client configured to connect to the above cluster with a pool > using PR-Single-Hop=true > *WHEN* *JustAFunction* is executed with onRegion and no filters > *IF* the client has partial metadata due to the cluster starting up or a > rebalance occurring > *THEN* and exception of type > *"org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException: > Multiple target nodes found for single hop operation"* is thrown by one of > the servers > --- > *Additional information.* Currently, in geode-native whenever the metadata > information is incomplete, and the user tries to execute the server function > with onRegion and no filters, a request of type > EXECUTE_REGION_FUNCTION_SINGLE_HOP is sent to each node. > But the issue is that bucket partition used by the client is incorrect, > leading consequently to the mentioned exception. > *Potential solution.* The potential solution would be to detect that the > metadata is incomplete before actually executing the function and send a > EXECUTE_REGION_FUNCTION request to one of the cluster nodes instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10400) Function execution triggering internal exception
Mario Salazar de Torres created GEODE-10400: --- Summary: Function execution triggering internal exception Key: GEODE-10400 URL: https://issues.apache.org/jira/browse/GEODE-10400 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a cluster with at least 3 members *AND* a partitioned region with 1 redundant-copy *AND* a server function called *JustAFunction* with isHA=false, hasResult=true, optimizeForWrite=true *AND* a native client configured to connect to the above cluster with a pool using PR-Single-Hop=true *WHEN* *JustAFunction* is executed with onRegion and no filters *IF* the client has partial metadata due to the cluster starting up or a rebalance occurring *THEN* and exception of type *"org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException: Multiple target nodes found for single hop operation"* is thrown by one of the servers --- *Additional information.* Currently, in geode-native whenever the metadata information is incomplete, and the user tries to execute the server function with onRegion and no filters, a request of type EXECUTE_REGION_FUNCTION_SINGLE_HOP is sent to each node. But the issue is that bucket partition used by the client is incorrect, leading consequently to the mentioned exception. *Potential solution.* The potential solution would be to detect that the metadata is incomplete before actually executing the function and send a EXECUTE_REGION_FUNCTION request to one of the cluster nodes instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10396) IllegalStateException wrapped within FunctionException triggers endpoint disconnection
Mario Salazar de Torres created GEODE-10396: --- Summary: IllegalStateException wrapped within FunctionException triggers endpoint disconnection Key: GEODE-10396 URL: https://issues.apache.org/jira/browse/GEODE-10396 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* A cluster of 3 servers and a client with a pool pointing to those 3 servers *AND* configured with PR-Singl-Hop = true *WHEN* A server function is executed with onRegion and with a filter *AND* it throws an IllegalServerException wrapped within a FunctionExceution in the body *THEN* the native client thinks there is an isue with the node and closes all the endpoint's connections. --- *IT IS TO BE EXPECTED* That given that the exception is wrapped inside a FunctionException this should be ignored by the endpoint failure detection mechanism that native client has into place. *AS ADDITIONAL INFO* Currently, the exception chain relationship info is not read by the native client, as it's serialized using Java serialization format. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10396) IllegalStateException wrapped within FunctionException triggers endpoint disconnection
[ https://issues.apache.org/jira/browse/GEODE-10396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10396: --- Assignee: Mario Salazar de Torres > IllegalStateException wrapped within FunctionException triggers endpoint > disconnection > -- > > Key: GEODE-10396 > URL: https://issues.apache.org/jira/browse/GEODE-10396 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* A cluster of 3 servers and a client with a pool pointing to those 3 > servers >*AND* configured with PR-Singl-Hop = true > *WHEN* A server function is executed with onRegion and with a filter >*AND* it throws an IllegalServerException wrapped within a > FunctionExceution in the body > *THEN* the native client thinks there is an isue with the node and closes all > the endpoint's connections. > --- > *IT IS TO BE EXPECTED* That given that the exception is wrapped inside a > FunctionException this should be ignored by the endpoint failure detection > mechanism that native client has into place. > *AS ADDITIONAL INFO* Currently, the exception chain relationship info is not > read by the native client, as it's serialized using Java serialization format. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10076: --- Assignee: Alberto Gomez (was: Mario Salazar de Torres) > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > *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 > Also I've noticed the following scenario requires to fix the codepoint > detection: > # 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. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
[ https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10276: --- Assignee: Mario Salazar de Torres > Refactor PDX (de)serialziation code to align it with Java client > > > Key: GEODE-10276 > URL: https://issues.apache.org/jira/browse/GEODE-10276 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > Currently there are the following open issues regarding PDX (de)serialization: > * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable > class|https://issues.apache.org/jira/browse/GEODE-9968] > * [GEODE-9753 - Coredump during PdxSerializable object > serialization|https://issues.apache.org/jira/browse/GEODE-9753] > * [GEODE-10220 - Coredump while initializing PdxType > remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] > * [GEODE-10255 - PdxSerializable not working correctly for multiple versions > of the same class|https://issues.apache.org/jira/browse/GEODE-10255] > Also, the implementation on this ticket ([GEODE-8212: Reduce connections to > server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) > poses some issues with PDX entries which fields are a permutation. Thing is > that PdxTypes which fields are a permutation might use the wrong offsets, > leading to a corrupt serialization. This is something that was not taken into > account at the time of getting this PR merged. > So this ticket should be reverted and possibly an alternative solution > proposed. > In order to tackle these issues, a code refactoring is needed to introduce > the following implementations: > * Single type of PdxWriter > * An implementation PdxReader that tracks unread data, and other that don't. > * An implementation for PdxInstances that guarantees that fields are > actually written in alphabetical order, independently of the writeFields call > order. This should tackle the issue described above regarding GEODE-8212. > * Also, it'd be ideal to make it so PDX code is cleaner and easier to > understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client
Mario Salazar de Torres created GEODE-10276: --- Summary: Refactor PDX (de)serialziation code to align it with Java client Key: GEODE-10276 URL: https://issues.apache.org/jira/browse/GEODE-10276 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently there are the following open issues regarding PDX (de)serialization: * [GEODE-9968 - Fix deserialization for new fields in PdxSerializable class|https://issues.apache.org/jira/browse/GEODE-9968] * [GEODE-9753 - Coredump during PdxSerializable object serialization|https://issues.apache.org/jira/browse/GEODE-9753] * [GEODE-10220 - Coredump while initializing PdxType remoteToLocal|https://issues.apache.org/jira/browse/GEODE-10220] * [GEODE-10255 - PdxSerializable not working correctly for multiple versions of the same class|https://issues.apache.org/jira/browse/GEODE-10255] Also, the implementation on this ticket ([GEODE-8212: Reduce connections to server to get type id|https://issues.apache.org/jira/browse/GEODE-8212]) poses some issues with PDX entries which fields are a permutation. Thing is that PdxTypes which fields are a permutation might use the wrong offsets, leading to a corrupt serialization. This is something that was not taken into account at the time of getting this PR merged. So this ticket should be reverted and possibly an alternative solution proposed. In order to tackle these issues, a code refactoring is needed to introduce the following implementations: * Single type of PdxWriter * An implementation PdxReader that tracks unread data, and other that don't. * An implementation for PdxInstances that guarantees that fields are actually written in alphabetical order, independently of the writeFields call order. This should tackle the issue described above regarding GEODE-8212. * Also, it'd be ideal to make it so PDX code is cleaner and easier to understand, though that's a complex matter, and also, subjective. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9941) Coredump during PdxSerializable object deserialization
[
https://issues.apache.org/jira/browse/GEODE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres resolved GEODE-9941.
Resolution: Duplicate
> Coredump during PdxSerializable object deserialization
> --
>
> Key: GEODE-9941
> URL: https://issues.apache.org/jira/browse/GEODE-9941
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> *GIVEN* a cluster with a single server and a single locator with a
> PdxSerializable like class implementation named Order
> *AND* a geode-native client with 1 PdxSerializable class implementation named
> Order, matching the implementation on the cluster
> *AND* also on-client-disconnect-clear-pdxType-Ids=true in client configuration
> *WHEN* an Order object is tried to be deserialized
> *WHILE* the cluster is being restarted
> *THEN* a coredump happens given that PdxType=nullptr
> —
> {*}Additional information{*}. As seen by early troubleshooting, the coredump
> happens because the pdx type is tried to be fetched from the PdxTypeRegistry
> by its class name, but the PdxTypeRegistry is cleaned up during serialization
> given that subscription redundancy was lost.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9941) Coredump during PdxSerializable object deserialization
[
https://issues.apache.org/jira/browse/GEODE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres closed GEODE-9941.
--
> Coredump during PdxSerializable object deserialization
> --
>
> Key: GEODE-9941
> URL: https://issues.apache.org/jira/browse/GEODE-9941
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> *GIVEN* a cluster with a single server and a single locator with a
> PdxSerializable like class implementation named Order
> *AND* a geode-native client with 1 PdxSerializable class implementation named
> Order, matching the implementation on the cluster
> *AND* also on-client-disconnect-clear-pdxType-Ids=true in client configuration
> *WHEN* an Order object is tried to be deserialized
> *WHILE* the cluster is being restarted
> *THEN* a coredump happens given that PdxType=nullptr
> —
> {*}Additional information{*}. As seen by early troubleshooting, the coredump
> happens because the pdx type is tried to be fetched from the PdxTypeRegistry
> by its class name, but the PdxTypeRegistry is cleaned up during serialization
> given that subscription redundancy was lost.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9322) Solve potential race condition in TransactionCleaningTest
[ https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-9322. Resolution: Fixed > Solve potential race condition in TransactionCleaningTest > - > > Key: GEODE-9322 > URL: https://issues.apache.org/jira/browse/GEODE-9322 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > A possible race condition was detected in this new IT. > Given there is no check for servers start/stop, it might happen that the test > proceeds before the server is actually stopped/started. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9322) Solve potential race condition in TransactionCleaningTest
[ https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-9322. -- > Solve potential race condition in TransactionCleaningTest > - > > Key: GEODE-9322 > URL: https://issues.apache.org/jira/browse/GEODE-9322 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > A possible race condition was detected in this new IT. > Given there is no check for servers start/stop, it might happen that the test > proceeds before the server is actually stopped/started. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10255) PdxSerializable not working correctly for multiple versions of the same class
[ https://issues.apache.org/jira/browse/GEODE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10255: --- Assignee: Mario Salazar de Torres > PdxSerializable not working correctly for multiple versions of the same class > - > > Key: GEODE-10255 > URL: https://issues.apache.org/jira/browse/GEODE-10255 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a couple of PdxSerializable implementations for the same class, let's > say v1 and v2 > *WHEN* you GET a v1 entry of this PdxSerializable just after client startup > and after that perform a PUT of v2 entry. > *THEN* the PUT operation uses the PdxType from v1 instead of the right one, > leading to data corruption -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10255) PdxSerializable not working correctly for multiple versions of the same class
Mario Salazar de Torres created GEODE-10255: --- Summary: PdxSerializable not working correctly for multiple versions of the same class Key: GEODE-10255 URL: https://issues.apache.org/jira/browse/GEODE-10255 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a couple of PdxSerializable implementations for the same class, let's say v1 and v2 *WHEN* you GET a v1 entry of this PdxSerializable just after client startup and after that perform a PUT of v2 entry. *THEN* the PUT operation uses the PdxType from v1 instead of the right one, leading to data corruption -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-10074. - Resolution: Fixed > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-10074. --- > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-9328. -- > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-9328. Resolution: Fixed > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10220) Coredump while initializing PdxType remoteToLocal
[ https://issues.apache.org/jira/browse/GEODE-10220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10220: --- Assignee: Mario Salazar de Torres > Coredump while initializing PdxType remoteToLocal > - > > Key: GEODE-10220 > URL: https://issues.apache.org/jira/browse/GEODE-10220 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a cluster with 1 server and 1 locator > *AND* a native client connected to the cluster > *WHEN* deserializing a PdxSerializable like object > *AND* and a new PdxType is fetched from the server > *THEN* a coredump happens whenever initializing the remoteToLocal map. > --- > *Additional information.* The coredump happens whenever > PdxType::initRemoteToLocal is called -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10220) Coredump while initializing PdxType remoteToLocal
Mario Salazar de Torres created GEODE-10220: --- Summary: Coredump while initializing PdxType remoteToLocal Key: GEODE-10220 URL: https://issues.apache.org/jira/browse/GEODE-10220 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a cluster with 1 server and 1 locator *AND* a native client connected to the cluster *WHEN* deserializing a PdxSerializable like object *AND* and a new PdxType is fetched from the server *THEN* a coredump happens whenever initializing the remoteToLocal map. --- *Additional information.* The coredump happens whenever PdxType::initRemoteToLocal is called -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10076: --- Assignee: Mario Salazar de Torres > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *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 > Also I've noticed the following scenario requires to fix the codepoint > detection: > # 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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10076) Fix string codepoint detection
[ https://issues.apache.org/jira/browse/GEODE-10076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-10076: Description: *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 Also I've noticed the following scenario requires to fix the codepoint detection: # 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. was: *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 > Fix string codepoint detection > -- > > Key: GEODE-10076 > URL: https://issues.apache.org/jira/browse/GEODE-10076 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *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 > Also I've noticed the following scenario requires to fix the codepoint > detection: > # 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. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10076) Fix string codepoint detection
Mario Salazar de Torres created GEODE-10076: --- Summary: Fix string codepoint detection Key: GEODE-10076 URL: https://issues.apache.org/jira/browse/GEODE-10076 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *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)
[jira] [Updated] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-10074: Labels: obliterate-ace (was: pull-request-available) > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10074: --- Assignee: Mario Salazar de Torres > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10074) Remove ACE remains
Mario Salazar de Torres created GEODE-10074: --- Summary: Remove ACE remains Key: GEODE-10074 URL: https://issues.apache.org/jira/browse/GEODE-10074 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *AS A* geode-native contributor *I WANT TO* remove all the ACE remaining *SO THAT* geode-native does not depends anymore on ACE -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-10074: Description: *AS A* geode-native contributor *I WANT TO* remove all the ACE remaining *SO THAT* geode-native does not depend on ACE anymore was: *AS A* geode-native contributor *I WANT TO* remove all the ACE remaining *SO THAT* geode-native does not depends anymore on ACE > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8750) Size tracking for LRUEntriesMap is not accurate
[ https://issues.apache.org/jira/browse/GEODE-8750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-8750: --- Affects Version/s: (was: 1.12.0) (was: 1.13.0) (was: 1.13.1) > Size tracking for LRUEntriesMap is not accurate > --- > > Key: GEODE-8750 > URL: https://issues.apache.org/jira/browse/GEODE-8750 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > LRUEntriesMap uses only key and value object size to keep track of the heap > memory consumed by the entries. > Thing is there are some more pieces of memory involved in storing this > entries and they are not being taken into account. Those are: > * Hash table internals memory (buckets, nodes...). > * Smart pointer internals (control block...). > * Any other memory used to store information about the LRUMap. > The purpose of this issue is to set the line on when it is reasonable to stop > measuring the heap memory consumed, and after that put in place a proper > implementation to track used heap memory within what's feasible. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9328: -- Assignee: Mario Salazar de Torres > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-8598) Fix PdxInstanceTest.testPdxInstance integration test
[ https://issues.apache.org/jira/browse/GEODE-8598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-8598. -- > Fix PdxInstanceTest.testPdxInstance integration test > > > Key: GEODE-8598 > URL: https://issues.apache.org/jira/browse/GEODE-8598 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > While working on another PR I tried to change PdxFieldType operator== so it > did not use className of the field rather than using the field's type. > After doing so, I noticed PdxInstanceTest.testPdxInstance was failing and > that was due to test PdxType serializable was reading/writing fields in a > different order than clonePdxInstance was writing it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8598) Fix PdxInstanceTest.testPdxInstance integration test
[ https://issues.apache.org/jira/browse/GEODE-8598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-8598: --- Affects Version/s: (was: 1.12.0) (was: 1.13.0) > Fix PdxInstanceTest.testPdxInstance integration test > > > Key: GEODE-8598 > URL: https://issues.apache.org/jira/browse/GEODE-8598 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > While working on another PR I tried to change PdxFieldType operator== so it > did not use className of the field rather than using the field's type. > After doing so, I noticed PdxInstanceTest.testPdxInstance was failing and > that was due to test PdxType serializable was reading/writing fields in a > different order than clonePdxInstance was writing it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-8598) Fix PdxInstanceTest.testPdxInstance integration test
[ https://issues.apache.org/jira/browse/GEODE-8598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-8598. Resolution: Not A Problem Does not seem like an issue in the latest version. > Fix PdxInstanceTest.testPdxInstance integration test > > > Key: GEODE-8598 > URL: https://issues.apache.org/jira/browse/GEODE-8598 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.12.0, 1.13.0 >Reporter: Mario Salazar de Torres >Priority: Major > > While working on another PR I tried to change PdxFieldType operator== so it > did not use className of the field rather than using the field's type. > After doing so, I noticed PdxInstanceTest.testPdxInstance was failing and > that was due to test PdxType serializable was reading/writing fields in a > different order than clonePdxInstance was writing it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8560) Implement JsonFormatter in NC
[ https://issues.apache.org/jira/browse/GEODE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-8560: --- Description: *AS AN* geode-native contributor *I WANT* to have a JsonFormatter solution in NC *SO THAT* I am able to convert between JSON objects and the other way around was: *AS AN* geode-native contributor *I WANT* to have a JsonFormatter solution in NC *SO THAT* I am able to convert between JSON objects and the other way around > Implement JsonFormatter in NC > - > > Key: GEODE-8560 > URL: https://issues.apache.org/jira/browse/GEODE-8560 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Priority: Major > Labels: JsonFormatter > > *AS AN* geode-native contributor > *I WANT* to have a JsonFormatter solution in NC > *SO THAT* I am able to convert between JSON objects and the other way around -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-8535) Coredump while putting an entry to a LocalRegion
[
https://issues.apache.org/jira/browse/GEODE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres closed GEODE-8535.
--
> Coredump while putting an entry to a LocalRegion
>
>
> Key: GEODE-8535
> URL: https://issues.apache.org/jira/browse/GEODE-8535
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Attachments: coredump.log, notifications-no-massif.log
>
>
> The scenario is the following:
> *GIVEN* concurrency-checks-enabled=true (as default) for the region in which
> the put operation is happening.
> *GIVEN* tombstone-timeout=10ms
> *WHENEVER* a huge load (hundreds per second) of LOCAL_CREATE, LOCAL_DESTROY
> notifications are received in the client for the same region and consecutive
> keys, as below example shows:
> {code:java}
> t_0: LOCAL_CREATE for key entry-1
> t_1: LOCAL_DESTROY for key entry-1
> t_2: LOCAL_CREATE for key entry-2
> t_3: LOCAL_DESTROY for key entry-2
> ·
> ·
> ·
> t_(2*(n-1)): LOCAL_CREATE for key entry-n
> t_(2*n-1): LOCAL_DESTROY for key entry-n{code}
> *THEN* the application crashes, in many different places, but as for the case
> reported here, whenever trying access the virtual destructor pointing of the
> ExpiryHandlerTask, which turns out to be nullptr.
>
> Find segmentation report attached as *coredump.log* and also, geode-native
> debug log attached as *notifications-no-massif.log*
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-8535) Coredump while putting an entry to a LocalRegion
[
https://issues.apache.org/jira/browse/GEODE-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres resolved GEODE-8535.
Resolution: Not A Problem
Closing this ticket as the issue it's not there any longer given it has been
solved on the time being.
> Coredump while putting an entry to a LocalRegion
>
>
> Key: GEODE-8535
> URL: https://issues.apache.org/jira/browse/GEODE-8535
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Attachments: coredump.log, notifications-no-massif.log
>
>
> The scenario is the following:
> *GIVEN* concurrency-checks-enabled=true (as default) for the region in which
> the put operation is happening.
> *GIVEN* tombstone-timeout=10ms
> *WHENEVER* a huge load (hundreds per second) of LOCAL_CREATE, LOCAL_DESTROY
> notifications are received in the client for the same region and consecutive
> keys, as below example shows:
> {code:java}
> t_0: LOCAL_CREATE for key entry-1
> t_1: LOCAL_DESTROY for key entry-1
> t_2: LOCAL_CREATE for key entry-2
> t_3: LOCAL_DESTROY for key entry-2
> ·
> ·
> ·
> t_(2*(n-1)): LOCAL_CREATE for key entry-n
> t_(2*n-1): LOCAL_DESTROY for key entry-n{code}
> *THEN* the application crashes, in many different places, but as for the case
> reported here, whenever trying access the virtual destructor pointing of the
> ExpiryHandlerTask, which turns out to be nullptr.
>
> Find segmentation report attached as *coredump.log* and also, geode-native
> debug log attached as *notifications-no-massif.log*
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494048#comment-17494048 ] Mario Salazar de Torres commented on GEODE-9328: Hi [~echobravo], I think all ongoing sub-tasks associated to this one have already a PR ready to review. This are the PRs: - [PR #812|https://github.com/apache/geode-native/pull/812] - [PR #813|https://github.com/apache/geode-native/pull/813] - [PR #814|https://github.com/apache/geode-native/pull/814] - [PR #815|https://github.com/apache/geode-native/pull/815] Also note once those are reviewed, probably we'll need to create another PR to cleanup the remainings such as CMakeLists I'll be more than glad to get any comments on those standing PRs :) BR, Mario. > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10044) Allow for FunctionAttributes to be updated
[ https://issues.apache.org/jira/browse/GEODE-10044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10044: --- Assignee: Mario Salazar de Torres > Allow for FunctionAttributes to be updated > --- > > Key: GEODE-10044 > URL: https://issues.apache.org/jira/browse/GEODE-10044 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Minor > > *AS A* geode-native contributor > *I WANT TO* to reset function attributes on-the-fly whenever a function > attributes mismatch is detected on the client > *SO THAT* FunctionAttributes can be changed during an upgrade scenario > > *Additional information.* Currently there is no exception being thrown from > the server whenever a function attributes missmatch is detected. Instead, a > function execution error is send to the client. So it remains to be tackled > how the mismatch is going to be detected on the client side. > *Also, for additional context,* this feature is designed in order to fulfill > the following upgrade scenario: > # A server function called ExampleFunction is deployed inside a cluster. > This server function is defined with isHA=false > # Function is executed several times from the client. > # After some time, a new version of ExampleFunction jar is deployed. The new > version of the server function is defined with isHA=true > # After updating the server function, executions for this function inside > the client should fail at most once, and after that, execute smoothly with > the new function attributes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-10043. --- > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-10043. - Resolution: Resolved > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10044) Allow for FunctionAttributes to be updated
[ https://issues.apache.org/jira/browse/GEODE-10044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-10044: Priority: Minor (was: Major) > Allow for FunctionAttributes to be updated > --- > > Key: GEODE-10044 > URL: https://issues.apache.org/jira/browse/GEODE-10044 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Minor > > *AS A* geode-native contributor > *I WANT TO* to reset function attributes on-the-fly whenever a function > attributes mismatch is detected on the client > *SO THAT* FunctionAttributes can be changed during an upgrade scenario > > *Additional information.* Currently there is no exception being thrown from > the server whenever a function attributes missmatch is detected. Instead, a > function execution error is send to the client. So it remains to be tackled > how the mismatch is going to be detected on the client side. > *Also, for additional context,* this feature is designed in order to fulfill > the following upgrade scenario: > # A server function called ExampleFunction is deployed inside a cluster. > This server function is defined with isHA=false > # Function is executed several times from the client. > # After some time, a new version of ExampleFunction jar is deployed. The new > version of the server function is defined with isHA=true > # After updating the server function, executions for this function inside > the client should fail at most once, and after that, execute smoothly with > the new function attributes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10044) Allow for FunctionAttributes to be updated
Mario Salazar de Torres created GEODE-10044: --- Summary: Allow for FunctionAttributes to be updated Key: GEODE-10044 URL: https://issues.apache.org/jira/browse/GEODE-10044 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *AS A* geode-native contributor *I WANT TO* to reset function attributes on-the-fly whenever a function attributes mismatch is detected on the client *SO THAT* FunctionAttributes can be changed during an upgrade scenario *Additional information.* Currently there is no exception being thrown from the server whenever a function attributes missmatch is detected. Instead, a function execution error is send to the client. So it remains to be tackled how the mismatch is going to be detected on the client side. *Also, for additional context,* this feature is designed in order to fulfill the following upgrade scenario: # A server function called ExampleFunction is deployed inside a cluster. This server function is defined with isHA=false # Function is executed several times from the client. # After some time, a new version of ExampleFunction jar is deployed. The new version of the server function is defined with isHA=true # After updating the server function, executions for this function inside the client should fail at most once, and after that, execute smoothly with the new function attributes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
[ https://issues.apache.org/jira/browse/GEODE-10043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-10043: --- Assignee: Mario Salazar de Torres > TransactionCleaningTest.txWithStoppedServer is sporiously failing > - > > Key: GEODE-10043 > URL: https://issues.apache.org/jira/browse/GEODE-10043 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > This new-IT is failing from time to time due to concurrent modification > exception. > Here there are some executions in which can be seen the failure: > - > [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] > - > [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10043) TransactionCleaningTest.txWithStoppedServer is sporiously failing
Mario Salazar de Torres created GEODE-10043: --- Summary: TransactionCleaningTest.txWithStoppedServer is sporiously failing Key: GEODE-10043 URL: https://issues.apache.org/jira/browse/GEODE-10043 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres This new-IT is failing from time to time due to concurrent modification exception. Here there are some executions in which can be seen the failure: - [https://concourse.apachegeode-ci.info/builds/25709909|https://concourse.apachegeode-ci.info/builds/25709909] - [https://concourse.apachegeode-ci.info/builds/26267825|https://concourse.apachegeode-ci.info/builds/26267825] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10026) Implement java deserialization
[ https://issues.apache.org/jira/browse/GEODE-10026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489818#comment-17489818 ] Mario Salazar de Torres commented on GEODE-10026: - Hi [~echobravo], You've got a good point, and I don't like it either. But the problem is that the current way that exceptions are handled inside the native client is not acceptable at all. Eitherway I'll let rest the exceptions part for now, and come back with some alternatives in the future. BR, Mario. > Implement java deserialization > -- > > Key: GEODE-10026 > URL: https://issues.apache.org/jira/browse/GEODE-10026 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Currently, the native client does not support deserializing Java serialized > objects. > I.E exceptions are sent as Java serialized and also a message is sent, so if > the Java serialized object could be read instead of the exception message, > this would solve several issues while parsing exceptions. > Java (de)serialization is an > [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] > so and has not changed in a while, so adding this would require so little > maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (GEODE-10029) Strings are not correctly serialized
[ https://issues.apache.org/jira/browse/GEODE-10029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489813#comment-17489813 ] Mario Salazar de Torres commented on GEODE-10029: - 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)
[jira] [Created] (GEODE-10029) Strings are not correctly serialized
Mario Salazar de Torres created GEODE-10029: --- Summary: 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 *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)
[jira] [Created] (GEODE-10027) Exception parsing using the Java serialized object
Mario Salazar de Torres created GEODE-10027: --- Summary: Exception parsing using the Java serialized object Key: GEODE-10027 URL: https://issues.apache.org/jira/browse/GEODE-10027 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, exceptions received in the native client are using just the exception message to identify the exceptions. Also there is the problem that the exception chain is lost, only the first identified exception in the message is thrown. Also there is the thing that it would be way easier to handle all kind of exceptions, and also, in the future, could allow to parse custom implemented exceptions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10026) Implement java deserialization
Mario Salazar de Torres created GEODE-10026: --- Summary: Implement java deserialization Key: GEODE-10026 URL: https://issues.apache.org/jira/browse/GEODE-10026 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, the native client does not support deserializing Java serialized objects. I.E exceptions are sent as Java serialized and also a message is sent, so if the Java serialized object could be read instead of the exception message, this would solve several issues while parsing exceptions. Java (de)serialization is an [standard|https://docs.oracle.com/javase/8/docs/platform/serialization/spec/protocol.html] so and has not changed in a while, so adding this would require so little maintenance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10025) Change TcrMessage response parse
Mario Salazar de Torres created GEODE-10025: --- Summary: Change TcrMessage response parse Key: GEODE-10025 URL: https://issues.apache.org/jira/browse/GEODE-10025 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres Currently, all implementations of TcrMessage are in the same file, and also, the response for any request is processed on the same place and under TcrMessageReply. I'd be ideal to split implementations on several files and also to try and parse response using some kind of factory instead of just a switch. This will dramatically improve code readability, hence will set the bases to identify several issues on message parsing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10024) Improve protocol parsing by introducing Parts
Mario Salazar de Torres created GEODE-10024: --- Summary: Improve protocol parsing by introducing Parts Key: GEODE-10024 URL: https://issues.apache.org/jira/browse/GEODE-10024 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres In order to limit serialization issues, and to make the message parsing code more readable, it would be good to have Parts introduced into the native client -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-10017:
---
Assignee: Mario Salazar de Torres
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486856#comment-17486856
]
Mario Salazar de Torres edited comment on GEODE-10017 at 2/4/22, 8:46 AM:
--
After some digging I noticed that for the executions on which one of these TCs
get stuck, GFSH tool running the "start server ..." command, never returns.
So I checked why GFSH was not returning and I saw that it was stuck checking
the server state, which was always returning as non-responding, even whenever
there was a server instance running (as I could see by connecting to the
cluster and running list member)/listing processes in the test
container/looking at the logs.
So, looking for all of the possible scenarios which could cause ServerState to
show up as "Not responding" I noticed that there were no PID file inside the
recently started server and this was causing the whole issue.
Now, my theory for why that's happening is the following:
# First instance of the server is notified to be stopped.
# Cache for the first server is closed, and GFSH process stopping the server
exists, returning the control to the test process.
# Given that the from the point of view of the test the server has been
stopped already, it runs the startup for the new server.
# The newer server instance writes the PID file with its PID.
# The older server instance, which was still running, deletes its PID along
some other files and actually terminate its process.
The time gap between step 4 and 5 normally is really tight, so that would
explain why this issue only reproduces sometimes and mostly on overloaded
systems.
was (Author: gaussianrecurrence):
After some digging I noticed that for the executions on which one of these TCs
get stuck, GFSH tool running the "start server ..." command, never returns.
So I checked why GFSH was not returning and I saw that it was stuck checking
the server state, which was always returning as non-responding, even whenever
there was a server instance running (as I could see by connecting to the
cluster and running list member)/listing processes in the test
container/looking at the logs.
So, looking for all of the possible scenarios which could cause ServerState to
show up as "Not responding" I noticed that there were no PID file inside the
recently started server and this was causing the whole issue.
Now, my theory for why that's happening is the following:
# First instance of the server is notified to be stopped.
# Cache for the first server is closed, and GFSH process stopping the server
exists, returning the control to the test process.
# Given that the from the point of view of the test the server has been
stopped already, it runs the startup for the new server.
# The newer server instance writes the PID file with its PID.
# The older server instance, which was still running, deletes its PID along
some other files and actually terminate its process.
The time gap between step 4 and 5 normally is really tight, so that would
explain why this issue only reproduces sometimes and mostly on overloaded
systems.
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-10017:
Summary: Fix new ITs unstability for TCs that involve members restart
(was: Fix new ITs unstability for TC that involves members restart)
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486856#comment-17486856
]
Mario Salazar de Torres commented on GEODE-10017:
-
After some digging I noticed that for the executions on which one of these TCs
get stuck, GFSH tool running the "start server ..." command, never returns.
So I checked why GFSH was not returning and I saw that it was stuck checking
the server state, which was always returning as non-responding, even whenever
there was a server instance running (as I could see by connecting to the
cluster and running list member)/listing processes in the test
container/looking at the logs.
So, looking for all of the possible scenarios which could cause ServerState to
show up as "Not responding" I noticed that there were no PID file inside the
recently started server and this was causing the whole issue.
Now, my theory for why that's happening is the following:
# First instance of the server is notified to be stopped.
# Cache for the first server is closed, and GFSH process stopping the server
exists, returning the control to the test process.
# Given that the from the point of view of the test the server has been
stopped already, it runs the startup for the new server.
# The newer server instance writes the PID file with its PID.
# The older server instance, which was still running, deletes its PID along
some other files and actually terminate its process.
The time gap between step 4 and 5 normally is really tight, so that would
explain why this issue only reproduces sometimes and mostly on overloaded
systems.
> Fix new ITs unstability for TC that involves members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-10017:
Description:
*GIVEN* an integration TC on which a server restart needs to be restarted
*WHEN* the server is starting up again
*THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC gets
stuck{color}
*Additional information.* This issue does not always happens, and I've seen it
happening more frequently with the latest version of Geode server (1.15.0)
Some examples of this TC are:
* RegisterKeysTest.RegisterKeySetAndClusterRestart
* PartitionRegionWithRedundancyTest.putgetWithSingleHop
* ···
Also, this is normally the exec flow for the TCs that get stuck:
# Setup cluster
# Do TC specific ops
# Stop server(s)/Cluster shutdown
# Start server(s)
In all cases, the server gets stuck at step 4
was:
*GIVEN* an integration TC on which a server restart needs to be restarted
*WHEN* the server is starting up again
*THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC gets
stuck{color}
*Additional information.* This issue does not always happens, and I've seen it
happening more frequently with the latest version of Geode server (1.15.0)
Some examples of this TC are:
* RegisterKeysTest.RegisterKeySetAndClusterRestart
* PartitionRegionWithRedundancyTest.putgetWithSingleHop
* ···
> Fix new ITs unstability for TC that involves members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-10017:
Description:
*GIVEN* an integration TC on which a server restart needs to be restarted
*WHEN* the server is starting up again
*THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC gets
stuck{color}
*Additional information.* This issue does not always happens, and I've seen it
happening more frequently with the latest version of Geode server (1.15.0)
Some examples of this TC are:
* RegisterKeysTest.RegisterKeySetAndClusterRestart
* PartitionRegionWithRedundancyTest.putgetWithSingleHop
* ···
was:
*GIVEN* an integration TC on which a server restart needs to be restarted
*WHEN* the server is starting up again
*THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC gets
stuck{color}
*Additional information.* This issue does not always happens, and I've seen it
happening more frequently with the latest version of Geode server (1.15.0)
> Fix new ITs unstability for TC that involves members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10017) Fix new ITs unstability for TC that involves members restart
Mario Salazar de Torres created GEODE-10017:
---
Summary: Fix new ITs unstability for TC that involves members
restart
Key: GEODE-10017
URL: https://issues.apache.org/jira/browse/GEODE-10017
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Mario Salazar de Torres
*GIVEN* an integration TC on which a server restart needs to be restarted
*WHEN* the server is starting up again
*THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC gets
stuck{color}
*Additional information.* This issue does not always happens, and I've seen it
happening more frequently with the latest version of Geode server (1.15.0)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10012) Avoid retries for non-HA function execution
Mario Salazar de Torres created GEODE-10012:
---
Summary: Avoid retries for non-HA function execution
Key: GEODE-10012
URL: https://issues.apache.org/jira/browse/GEODE-10012
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Mario Salazar de Torres
*GIVEN* a cluster with 3 servers and 1 locator
*AND* a PartitionedRegion with redundant-copies="1"
*AND* a user-defined Function with isHA=false
*AND* a geode-native client with a pool with single-hop enabled and retry
attempts set to 2
*WHEN* execution fails due to a connectivity issue/connection timeout/internal
cluster error
*THEN* function is retried twice
*Additional information.* The function is retried at the network code layer,
and given whenever there is a timeout/connectivity error, the BSL is removed
from the ClientMetadataService, whenever retries happen, you might get a
*InternalFunctionInvocationTargetException* exception thrown indicating:
{code:java}
Multiple target nodes found for single hop operation {code}
Also, have into account that Java client API behaviour never retries a Function
Execution if isHA=false for that function, and whenever isHA=true, the function
is retried but on the function execution logic and not at the networking layer.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-10012:
---
Assignee: Mario Salazar de Torres
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9968) Fix deserialization for new fields in PdxSerializable class
[ https://issues.apache.org/jira/browse/GEODE-9968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9968: -- Assignee: Mario Salazar de Torres > Fix deserialization for new fields in PdxSerializable class > --- > > Key: GEODE-9968 > URL: https://issues.apache.org/jira/browse/GEODE-9968 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* an implementation of a PdxSerializable class > *WHEN* a set of entries have been written for this class > *AND* after a while, the implementation changes, adding new fields > *AND* a new set of entries are written containing some of the added fields > *AND* all of the region entries are read > *THEN* added fields of the latest entries are empty or contain garbage instead > > *Additional information.* After analyzing Java implementation for > PdxSerializable deserialization, it seems that the client fetches the > PdxFields from the remote PdxType, but instead for the C++ implementation, > code is different as it uses a mapping called "Local2Remote" (which I suppose > it's an optimization). And the current use of this "Local2Remote" mapping is > not working correctly under the described scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9968) Fix deserialization for new fields in PdxSerializable class
Mario Salazar de Torres created GEODE-9968: -- Summary: Fix deserialization for new fields in PdxSerializable class Key: GEODE-9968 URL: https://issues.apache.org/jira/browse/GEODE-9968 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* an implementation of a PdxSerializable class *WHEN* a set of entries have been written for this class *AND* after a while, the implementation changes, adding new fields *AND* a new set of entries are written containing some of the added fields *AND* all of the region entries are read *THEN* added fields of the latest entries are empty or contain garbage instead *Additional information.* After analyzing Java implementation for PdxSerializable deserialization, it seems that the client fetches the PdxFields from the remote PdxType, but instead for the C++ implementation, code is different as it uses a mapping called "Local2Remote" (which I suppose it's an optimization). And the current use of this "Local2Remote" mapping is not working correctly under the described scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9959: -- Assignee: Mario Salazar de Torres > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9959) Add FQDN during SSL handshake error while reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9959: --- Summary: Add FQDN during SSL handshake error while reaching a locator (was: Add FQDN during SSL handshake error when reaching a locator) > Add FQDN during SSL handshake error while reaching a locator > > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9959) Add FQDN during SSL handshake error when reaching a locator
[ https://issues.apache.org/jira/browse/GEODE-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9959: --- Summary: Add FQDN during SSL handshake error when reaching a locator (was: Add FQDN in SSL handshake error when reaching a locator) > Add FQDN during SSL handshake error when reaching a locator > --- > > Key: GEODE-9959 > URL: https://issues.apache.org/jira/browse/GEODE-9959 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > *WHEN* a geode-native client tries to reach a locator > *AND* the locator being reached has SSL configured > *BUT* the geode-native client does not have SSL configured > *THEN* a log will be written indicating the issue > *AND* an AuthenticationRequiredException exception will be thrown, which > can't be catched > The improvement proposed here is to log the FQDN of the locator being reached > in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9959) Add FQDN in SSL handshake error when reaching a locator
Mario Salazar de Torres created GEODE-9959: -- Summary: Add FQDN in SSL handshake error when reaching a locator Key: GEODE-9959 URL: https://issues.apache.org/jira/browse/GEODE-9959 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *WHEN* a geode-native client tries to reach a locator *AND* the locator being reached has SSL configured *BUT* the geode-native client does not have SSL configured *THEN* a log will be written indicating the issue *AND* an AuthenticationRequiredException exception will be thrown, which can't be catched The improvement proposed here is to log the FQDN of the locator being reached in order to have further information when troubleshooting this kind of issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9941) Coredump during PdxSerializable object deserialization
[
https://issues.apache.org/jira/browse/GEODE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres reassigned GEODE-9941:
--
Assignee: Mario Salazar de Torres
> Coredump during PdxSerializable object deserialization
> --
>
> Key: GEODE-9941
> URL: https://issues.apache.org/jira/browse/GEODE-9941
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> *GIVEN* a cluster with a single server and a single locator with a
> PdxSerializable like class implementation named Order
> *AND* a geode-native client with 1 PdxSerializable class implementation named
> Order, matching the implementation on the cluster
> *AND* also on-client-disconnect-clear-pdxType-Ids=true in client configuration
> *WHEN* an Order object is tried to be deserialized
> *WHILE* the cluster is being restarted
> *THEN* a coredump happens given that PdxType=nullptr
> —
> {*}Additional information{*}. As seen by early troubleshooting, the coredump
> happens because the pdx type is tried to be fetched from the PdxTypeRegistry
> by its class name, but the PdxTypeRegistry is cleaned up during serialization
> given that subscription redundancy was lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9941) Coredump during PdxSerializable object deserialization
[
https://issues.apache.org/jira/browse/GEODE-9941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-9941:
---
Description:
*GIVEN* a cluster with a single server and a single locator with a
PdxSerializable like class implementation named Order
*AND* a geode-native client with 1 PdxSerializable class implementation named
Order, matching the implementation on the cluster
*AND* also on-client-disconnect-clear-pdxType-Ids=true in client configuration
*WHEN* an Order object is tried to be deserialized
*WHILE* the cluster is being restarted
*THEN* a coredump happens given that PdxType=nullptr
—
{*}Additional information{*}. As seen by early troubleshooting, the coredump
happens because the pdx type is tried to be fetched from the PdxTypeRegistry by
its class name, but the PdxTypeRegistry is cleaned up during serialization
given that subscription redundancy was lost.
was:
*GIVEN* a cluster with a single server and a single locator with a
PdxSerializable like class implementation named Order
*AND* a geode-native client with 1 PdxSerializable class implementation named
Order, matching the implementation on the cluster
*WHEN* an Order object is tried to be deserialized
*WHILE* the cluster is being restarted
*THEN* a coredump happens given that PdxType=nullptr
> Coredump during PdxSerializable object deserialization
> --
>
> Key: GEODE-9941
> URL: https://issues.apache.org/jira/browse/GEODE-9941
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>
> *GIVEN* a cluster with a single server and a single locator with a
> PdxSerializable like class implementation named Order
> *AND* a geode-native client with 1 PdxSerializable class implementation named
> Order, matching the implementation on the cluster
> *AND* also on-client-disconnect-clear-pdxType-Ids=true in client configuration
> *WHEN* an Order object is tried to be deserialized
> *WHILE* the cluster is being restarted
> *THEN* a coredump happens given that PdxType=nullptr
> —
> {*}Additional information{*}. As seen by early troubleshooting, the coredump
> happens because the pdx type is tried to be fetched from the PdxTypeRegistry
> by its class name, but the PdxTypeRegistry is cleaned up during serialization
> given that subscription redundancy was lost.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9941) Coredump during PdxSerializable object deserialization
Mario Salazar de Torres created GEODE-9941: -- Summary: Coredump during PdxSerializable object deserialization Key: GEODE-9941 URL: https://issues.apache.org/jira/browse/GEODE-9941 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* a cluster with a single server and a single locator with a PdxSerializable like class implementation named Order *AND* a geode-native client with 1 PdxSerializable class implementation named Order, matching the implementation on the cluster *WHEN* an Order object is tried to be deserialized *WHILE* the cluster is being restarted *THEN* a coredump happens given that PdxType=nullptr -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9868) geode-native docker build images are not compiling correctly
[ https://issues.apache.org/jira/browse/GEODE-9868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9868: --- Description: Given that currently Geode version specified in the docker build images for geode-native is 1.13.2 and latests test introduces uses an Authentication feature only available in 1.15.0 (develop), current docker build images are failing to compile the source. The solution would require to have the latest version of geode included within the generated images. was: Given that currently Geode version specified in the docker build image for geode-native is 1.13.2 and latests test introduces uses an Authentication feature only available in 1.15.0 (develop), current docker build images are failing to compile the source. The solution would require to have the latest version of geode included within the generated images. > geode-native docker build images are not compiling correctly > - > > Key: GEODE-9868 > URL: https://issues.apache.org/jira/browse/GEODE-9868 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Given that currently Geode version specified in the docker build images for > geode-native is 1.13.2 and latests test introduces uses an Authentication > feature only available in 1.15.0 (develop), current docker build images are > failing to compile the source. > The solution would require to have the latest version of geode included > within the generated images. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9868) geode-native docker build images are not compiling correctly
[ https://issues.apache.org/jira/browse/GEODE-9868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9868: --- Description: Given that currently Geode version specified in the docker build images for geode-native is 1.13.2, and latest tests introduces an Authentication feature only available in 1.15.0 (develop), current docker build images are failing to compile the source. The solution would require to have the latest version of geode included within the generated images. was: Given that currently Geode version specified in the docker build images for geode-native is 1.13.2 and latests test introduces uses an Authentication feature only available in 1.15.0 (develop), current docker build images are failing to compile the source. The solution would require to have the latest version of geode included within the generated images. > geode-native docker build images are not compiling correctly > - > > Key: GEODE-9868 > URL: https://issues.apache.org/jira/browse/GEODE-9868 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > > Given that currently Geode version specified in the docker build images for > geode-native is 1.13.2, and latest tests introduces an Authentication feature > only available in 1.15.0 (develop), current docker build images are failing > to compile the source. > The solution would require to have the latest version of geode included > within the generated images. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9868) geode-native docker build images are not compiling correctly
Mario Salazar de Torres created GEODE-9868: -- Summary: geode-native docker build images are not compiling correctly Key: GEODE-9868 URL: https://issues.apache.org/jira/browse/GEODE-9868 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres Given that currently Geode version specified in the docker build image for geode-native is 1.13.2 and latests test introduces uses an Authentication feature only available in 1.15.0 (develop), current docker build images are failing to compile the source. The solution would require to have the latest version of geode included within the generated images. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9753: -- Assignee: Mario Salazar de Torres > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9753) Coredump during PdxSerializable object serialization
Mario Salazar de Torres created GEODE-9753: -- Summary: Coredump during PdxSerializable object serialization Key: GEODE-9753 URL: https://issues.apache.org/jira/browse/GEODE-9753 Project: Geode Issue Type: Bug Components: native client Reporter: Mario Salazar de Torres *GIVEN* **a single server and locator cluster with 1 PdxSerializable class registered, named Order *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class registered, named Order *WHEN* a Order object is tried to be serialized *WHILE* the cluster is being restarted *THEN* a coredump happens due to PdxType=nullptr — *Additional information*. As seen by early troubleshooting, the coredump happens because the pdx type is tried to be fetched from the PdxTypeRegist by its class name, but the PdxTypeRegistry is cleaned up during serialization given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9478) Fix member status logic when directory specified
[ https://issues.apache.org/jira/browse/GEODE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9478: --- Priority: Minor (was: Major) > Fix member status logic when directory specified > > > Key: GEODE-9478 > URL: https://issues.apache.org/jira/browse/GEODE-9478 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Minor > > As result of doing some tests with the status GFSH command in a cloud native > environment, it has been noticed that when --dir option, the internal logic, > if API attachment is enabled, tries to access the JMX interface to query the > server status. > And in order to obtain the JMX URL, the logic tries to attach to the member > with its PID. But, the thing is that in the problematic use case, both the > member and Gfsh/equivalent app using Gfsh API are in different containers, > and such containers do not share the PID namespace. > When both member and the status requesting application have different PIDs > the request fails given that the requesting application can't locate the > member PID on its namespace, sending a SIGQUIT (in a unix-like env) and > throwing an exception stating "no such process...". And if the internal logic > notices that the process couldn't be found, instead of failing over the > FileProcessController, it propagates the exception, causing the status > request to fail. > Additionally it has been observed that with the current logic, the status > command success if and only if the PID of the application executing the > status command, and the PID of the member are the same. I.E: PID 1 > The reason for that apparently is that there is some check in the JVM > attachment API that verifies if the PID of the JVM you are trying to attach > is the same as yours. If that's the case, it supposes that you are trying to > attach to yourself and throws an exception. > In that case, the exception is catched by the internal logic and the status > request failovers to the FileProcessController. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9478) Fix member status logic when directory specified
[ https://issues.apache.org/jira/browse/GEODE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9478: -- Assignee: Mario Salazar de Torres > Fix member status logic when directory specified > > > Key: GEODE-9478 > URL: https://issues.apache.org/jira/browse/GEODE-9478 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > As result of doing some tests with the status GFSH command in a cloud native > environment, it has been noticed that when --dir option, the internal logic, > if API attachment is enabled, tries to access the JMX interface to query the > server status. > And in order to obtain the JMX URL, the logic tries to attach to the member > with its PID. But, the thing is that in the problematic use case, both the > member and Gfsh/equivalent app using Gfsh API are in different containers, > and such containers do not share the PID namespace. > When both member and the status requesting application have different PIDs > the request fails given that the requesting application can't locate the > member PID on its namespace, sending a SIGQUIT (in a unix-like env) and > throwing an exception stating "no such process...". And if the internal logic > notices that the process couldn't be found, instead of failing over the > FileProcessController, it propagates the exception, causing the status > request to fail. > Additionally it has been observed that with the current logic, the status > command success if and only if the PID of the application executing the > status command, and the PID of the member are the same. I.E: PID 1 > The reason for that apparently is that there is some check in the JVM > attachment API that verifies if the PID of the JVM you are trying to attach > is the same as yours. If that's the case, it supposes that you are trying to > attach to yourself and throws an exception. > In that case, the exception is catched by the internal logic and the status > request failovers to the FileProcessController. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9478) Fix member status logic when directory specified
Mario Salazar de Torres created GEODE-9478: -- Summary: Fix member status logic when directory specified Key: GEODE-9478 URL: https://issues.apache.org/jira/browse/GEODE-9478 Project: Geode Issue Type: Bug Components: core Reporter: Mario Salazar de Torres As result of doing some tests with the status GFSH command in a cloud native environment, it has been noticed that when --dir option, the internal logic, if API attachment is enabled, tries to access the JMX interface to query the server status. And in order to obtain the JMX URL, the logic tries to attach to the member with its PID. But, the thing is that in the problematic use case, both the member and Gfsh/equivalent app using Gfsh API are in different containers, and such containers do not share the PID namespace. When both member and the status requesting application have different PIDs the request fails given that the requesting application can't locate the member PID on its namespace, sending a SIGQUIT (in a unix-like env) and throwing an exception stating "no such process...". And if the internal logic notices that the process couldn't be found, instead of failing over the FileProcessController, it propagates the exception, causing the status request to fail. Additionally it has been observed that with the current logic, the status command success if and only if the PID of the application executing the status command, and the PID of the member are the same. I.E: PID 1 The reason for that apparently is that there is some check in the JVM attachment API that verifies if the PID of the JVM you are trying to attach is the same as yours. If that's the case, it supposes that you are trying to attach to yourself and throws an exception. In that case, the exception is catched by the internal logic and the status request failovers to the FileProcessController. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9327) Remove all remaining references to ACE networking
[ https://issues.apache.org/jira/browse/GEODE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9327: -- Assignee: Mario Salazar de Torres > Remove all remaining references to ACE networking > - > > Key: GEODE-9327 > URL: https://issues.apache.org/jira/browse/GEODE-9327 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE networking > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9326) Remove ACE_Get_Opt references
[ https://issues.apache.org/jira/browse/GEODE-9326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9326: -- Assignee: Mario Salazar de Torres > Remove ACE_Get_Opt references > - > > Key: GEODE-9326 > URL: https://issues.apache.org/jira/browse/GEODE-9326 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Get_Opt > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9324: -- Assignee: Mario Salazar de Torres > Remove ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9323) Remove ACE references from tests/cpp
[ https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9323: -- Assignee: Mario Salazar de Torres > Remove ACE references from tests/cpp > > > Key: GEODE-9323 > URL: https://issues.apache.org/jira/browse/GEODE-9323 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE in tests/cpp projects > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9325) Remove ACE_Process references
[ https://issues.apache.org/jira/browse/GEODE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9325: -- Assignee: Mario Salazar de Torres > Remove ACE_Process references > - > > Key: GEODE-9325 > URL: https://issues.apache.org/jira/browse/GEODE-9325 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Process > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9324) Remove ACE_Task references
[ https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9324: --- Labels: obliterate-ace (was: ) > Remove ACE_Task references > -- > > Key: GEODE-9324 > URL: https://issues.apache.org/jira/browse/GEODE-9324 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Task > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9323) Remove ACE references from tests/cpp
[ https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9323: --- Labels: obliterate-ace (was: ) > Remove ACE references from tests/cpp > > > Key: GEODE-9323 > URL: https://issues.apache.org/jira/browse/GEODE-9323 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE in tests/cpp projects > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9328) Cleanup remains of ACE library
Mario Salazar de Torres created GEODE-9328: -- Summary: Cleanup remains of ACE library Key: GEODE-9328 URL: https://issues.apache.org/jira/browse/GEODE-9328 Project: Geode Issue Type: Improvement Components: native client Reporter: Mario Salazar de Torres *AS A* native client contributor *I WANT TO* remove all remaining references to ACE library *SO THAT* eventually we can get rid of ACE library *Additional information.* Note that all header inclusions, lib linkage and CMake dependency project will need to be cleaned up here. Also, additional changes might be needed to make the project compile, take it into account. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9325) Remove ACE_Process references
[ https://issues.apache.org/jira/browse/GEODE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9325: --- Labels: obliterate-ace (was: ) > Remove ACE_Process references > - > > Key: GEODE-9325 > URL: https://issues.apache.org/jira/browse/GEODE-9325 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE_Process > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.3.4#803005)
