[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2023-11-17 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787312#comment-17787312
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on PR #969:
URL: https://github.com/apache/geode-native/pull/969#issuecomment-1816770033

   I haven't had the time to work on this for a long time or I think I'll have 
the opportunity to in the near future, hence I am closing this PR, if anyone 
wants to tackle this issue can take it up from its latest state.




> 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
>  Labels: pull-request-available
>
> 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.10#820010)


[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2023-11-17 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787313#comment-17787313
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence closed pull request #969: GEODE-10276: Refactor PDX 
(de)serialization code
URL: https://github.com/apache/geode-native/pull/969




> 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
>  Labels: pull-request-available
>
> 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.10#820010)


[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-18 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538956#comment-17538956
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on PR #969:
URL: https://github.com/apache/geode-native/pull/969#issuecomment-1130249492

   @pivotal-jbarrett I've addressed all of your comments, plus I've fixed some 
logic issues and introduced some changes, mostly to cover all edge cases. 
Additionally, added a bunch of new tests to verify the functionality refactored 
by the change. So long store sort, I've marked the PR as ready for review, any 
comments are welcomed :)




> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534432#comment-17534432
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869428049


##
cppcache/src/CacheImpl.hpp:
##
@@ -134,6 +134,12 @@ class APACHE_GEODE_EXPORT CacheImpl {
*/
   DistributedSystem& getDistributedSystem();

Review Comment:
   Seems feasible :)





> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534385#comment-17534385
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869351686


##
cppcache/integration/test/PdxInstanceTest.cpp:
##
@@ -268,7 +268,7 @@ TEST(PdxInstanceTest, testPdxInstance) {
   pdxTypeFromPdxTypeInstance->equals(*pdxTypeFromPdxTypeInstanceGet, 
false))
   << "PdxObjects should be equal.";
 
-  EXPECT_EQ(-960665662, pdxTypeInstance->hashcode())
+  EXPECT_EQ(514863279, pdxTypeInstance->hashcode())

Review Comment:
   Damn, I did not thought of the fact that it was possible to use a 
PdxInstance as a key. Really thanks for pointing this out,





> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534381#comment-17534381
 ] 

ASF GitHub Bot commented on GEODE-10276:


pivotal-jbarrett commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869330026


##
cppcache/integration/test/PdxInstanceTest.cpp:
##
@@ -268,7 +268,7 @@ TEST(PdxInstanceTest, testPdxInstance) {
   pdxTypeFromPdxTypeInstance->equals(*pdxTypeFromPdxTypeInstanceGet, 
false))
   << "PdxObjects should be equal.";
 
-  EXPECT_EQ(-960665662, pdxTypeInstance->hashcode())
+  EXPECT_EQ(514863279, pdxTypeInstance->hashcode())

Review Comment:
   Why did this hash code change? Are we certain it matches the same hash that 
the server produces for it? If not this can lead to really bad single hop 
performance.



##
tests/javaobject/PdxTests/DeliveryAddress.java:
##
@@ -0,0 +1,82 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package PdxTests;
+
+import java.util.Vector;
+import org.apache.geode.pdx.PdxReader;
+import org.apache.geode.pdx.PdxSerializable;
+import org.apache.geode.pdx.PdxWriter;
+
+public class DeliveryAddress implements PdxSerializable
+{
+String _addressLine;

Review Comment:
   Geode's Java conventions come from the Google Java Style Guide. Please don't 
prefix member variables. Also please make this private.



##
cppcache/integration/test/PdxSerializableTest.cpp:
##
@@ -0,0 +1,157 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "DeliveryAddress.hpp"
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::Cacheable;
+using apache::geode::client::CacheableString;
+using apache::geode::client::CacheableVector;
+using apache::geode::client::FunctionService;
+using apache::geode::client::PdxReader;
+using apache::geode::client::PdxSerializable;
+using apache::geode::client::PdxWriter;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+using PdxTests::DeliveryAddress;
+
+std::shared_ptr setupRegion(Cache& cache) {
+  auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName("default")
+.create("region");
+
+  return region;
+}
+
+/**
+ * This test perform the following steps:
+ * 1. Writes a version 1 entry of DeliveryAddress named 'entry.v1'
+ * 2. From another cache, fetches the entry 'entry.v1'
+ * 3. From the same cache as step 2, it call function PutDeliveryAddress that
+ *writes a version 2 entry of DeliveryAddress named 'entry.v2'
+ * 4. From another cache, try to fetch the entry 'entry.v2' and it should match
+ *the entry written in step 3
+ *
+ * The purpose of this test is to verify that even if there are 2 versions of
+ * the same PdxSerializable class, the right PdxType will be used during
+ * (de)serialization
+ */
+TEST(PdxSerializableTest, testRightPdxTypeForDiffPdxVersions) {
+  Cluster cluster{LocatorCount{1}, ServerCount{1}};
+  cluster.start([&]() {
+cluster.getGfsh()
+.deploy()
+.jar(getFrameworkString(FrameworkVariable::JavaObjectJarPath))
+.execute();
+  });
+  cluster.getGfsh()
+  .create()
+  .region(

[jira] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534367#comment-17534367
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on PR #969:
URL: https://github.com/apache/geode-native/pull/969#issuecomment-1122476087

   > I realize this is a draft but was excited to take a peek and noticed this 
one right away.
   
   Yes, this is a WIP, there are some minor changes i yet want to make, and 
whole lot more of tests that I want to add, given the size of the change




> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534361#comment-17534361
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869302660


##
cppcache/src/CacheableObjectArray.cpp:
##
@@ -53,6 +54,18 @@ size_t CacheableObjectArray::objectSize() const {
   }
   return size;
 }
+
+std::string CacheableObjectArray::getClassName() const {
+  if (!empty()) {
+auto&& item = *begin();
+
+if (auto pdx = dynamic_cast(item.get())) {
+  return pdx->getClassName();
+}
+  }
+
+  return "java.lang.Object";

Review Comment:
   Thanks for pointing it out :)





> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534349#comment-17534349
 ] 

ASF GitHub Bot commented on GEODE-10276:


pivotal-jbarrett commented on code in PR #969:
URL: https://github.com/apache/geode-native/pull/969#discussion_r869292240


##
cppcache/src/CacheableObjectArray.cpp:
##
@@ -53,6 +54,18 @@ size_t CacheableObjectArray::objectSize() const {
   }
   return size;
 }
+
+std::string CacheableObjectArray::getClassName() const {
+  if (!empty()) {
+auto&& item = *begin();
+
+if (auto pdx = dynamic_cast(item.get())) {
+  return pdx->getClassName();
+}
+  }
+
+  return "java.lang.Object";

Review Comment:
   What if we make this string a `const` value in this compilation unit and 
change the return type of this method to return `const std::string&` so we 
aren't copy constructing strings on return.





> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534347#comment-17534347
 ] 

ASF GitHub Bot commented on GEODE-10276:


pivotal-jbarrett commented on PR #969:
URL: https://github.com/apache/geode-native/pull/969#issuecomment-1122447052

   OMG! Awesome effort!




> 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
>  Labels: pull-request-available
>
> 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] [Commented] (GEODE-10276) Refactor PDX (de)serialziation code to align it with Java client

2022-05-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534346#comment-17534346
 ] 

ASF GitHub Bot commented on GEODE-10276:


gaussianrecurrence opened a new pull request, #969:
URL: https://github.com/apache/geode-native/pull/969

- Code related to PDX de(serialization) has been refactored and aligned
  (in all possible means) to the Java client, solving the following
  issues:
   * GEODE-9968 - Fix deserialization for new fields in PdxSerializable
 class
   * GEODE-9753 - Coredump during PdxSerializable object serialization
   * GEODE-10220 - Coredump while initializing PdxType remoteToLocal
   * GEODE-10255 - PdxSerializable not working correctly for multiple
 versions of the same class
- Reverted GEODE-8212, to solve potential issues during (de)serialization.
  This is due to the fact that the server orders PdxType fields
  sequentially, rather than alphabetically.
- In order to achieve what was originally intended with GEODE-8212,
  now PdxInstances fields are written in alphabetical order, rather
  than in the order writeXX is called.
- Also, code now should be easier to understand
- Several tests modified to adapt to code changes
- Added several UTs to further incrase coverage on PDX (de)serialization 
code.
- Added several ITs to verify PDX (de)serialization scenarios.




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