[jira] [Commented] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140215#comment-17140215 ] ASF GitHub Bot commented on GEODE-8272: --- jinmeiliao merged pull request #5249: URL: https://github.com/apache/geode/pull/5249 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140115#comment-17140115
]
ASF GitHub Bot commented on GEODE-8212:
---
pivotal-jbarrett commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442594400
##
File path: cppcache/src/PdxType.cpp
##
@@ -568,16 +568,32 @@ bool PdxType::operator<(const PdxType& other) const {
return false;
}
-int32_t PdxType::hashcode() const {
+bool PdxType::operator==(const PdxType& other) const {
+ if (this->m_className != other.m_className){
+return false;
+ }
+
+ if(this->m_noJavaClass != other.m_noJavaClass){
+return false;
+ }
+
+ if(this->getTotalFields() != other.getTotalFields()){
+return false;
+ }
+
+ //TODO: Compare m_pdxFieldTypes & other.m_pdxFieldTypes;
+ return true;
+}
+
+size_t PdxType::hashcode() const {
std::hash strHash;
- auto result=strHash(this->m_className);
+ auto result = strHash(this->m_className);
- for (std::vector>::iterator it =
- m_pdxFieldTypes->begin();
+ for (auto it = m_pdxFieldTypes->begin();
Review comment:
Can we use a range `for` loop here.
##
File path: cppcache/src/PdxType.cpp
##
@@ -568,16 +568,32 @@ bool PdxType::operator<(const PdxType& other) const {
return false;
}
-int32_t PdxType::hashcode() const {
+bool PdxType::operator==(const PdxType& other) const {
+ if (this->m_className != other.m_className){
+return false;
+ }
+
+ if(this->m_noJavaClass != other.m_noJavaClass){
+return false;
+ }
+
+ if(this->getTotalFields() != other.getTotalFields()){
+return false;
+ }
+
+ //TODO: Compare m_pdxFieldTypes & other.m_pdxFieldTypes;
Review comment:
What's with the new TODO?
##
File path: cppcache/src/PdxType.hpp
##
@@ -205,10 +205,25 @@ class PdxType : public internal::DataSerializableInternal,
// This is for PdxType as key in std map.
bool operator<(const PdxType& other) const;
- int32_t hashcode() const;
+ bool operator==(const PdxType& other) const;
+
+ size_t hashcode() const;
};
} // namespace client
} // namespace geode
} // namespace apache
+namespace std {
+
+template <>
+struct hash {
+ typedef apache::geode::client::PdxType argument_type;
+ typedef size_t result_type;
+ result_type operator()(const argument_type& val) const {
+return val.hashcode();
Review comment:
Technically we can take the `hashcode` method off the `PdxType` and line
it here. The hash is only used for `std::hash` so let's not split it across the
two classes.
##
File path: cppcache/src/PdxType.hpp
##
@@ -205,10 +205,25 @@ class PdxType : public internal::DataSerializableInternal,
// This is for PdxType as key in std map.
bool operator<(const PdxType& other) const;
Review comment:
If we aren't going to use the std::map anymore perhaps we should remove
this `operator<`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140068#comment-17140068
]
ASF GitHub Bot commented on GEODE-8212:
---
pdxcodemonkey commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442566625
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
And now I think we see why PdxTests::PdxType existed in the first place.
apache::geode::client::PdxType is hidden in the library. The following fixes
linker errors for me, in cppcache/src/PdxType.hpp:
```
- class PdxType
+ class APACHE_GEODE_EXPORT PdxType
```
But now we need to have the more philosophical question about whether or not
this is the right thing to do. If we _are_ going to export PdxType, the header
needs to move from cppcache/src to cppcache/include/geode. @pivotal-jbarrett
any opinion/suggestion?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140065#comment-17140065
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442559744
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
> the following change worked for me on line 183 (the first spot I was
hitting a compiler gripe):
Nice, its simpler that the code I have just added. Now with the current
code, you should see the linker error I was not able to solve:
```
PdxJsonTypeTest.cpp:166: undefined reference to
`apache::geode::client::PdxType::PdxType(apache::geode::client::PdxTypeRegistry&,
std::__cxx11::basic_string, std::allocator
> const&, bool)'
...
and more linker errors from this point
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx):
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140063#comment-17140063
]
ASF GitHub Bot commented on GEODE-8212:
---
pdxcodemonkey commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442558468
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
After commenting out the using statement for PdxTest::PdxType, I found
the declaration of std::hash wasn't correct in the code (trying to pass 1 param
to ctor). the following change worked for me on line 183 (the first spot I was
hitting a compiler gripe):
```-
EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+ EXPECT_EQ(std::hash{}(m_pdxType1),
std::hash{}(m_pdxType2));
```
I expect the rest are similar...
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140062#comment-17140062
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442558585
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
The first linker error is the following:
```
PdxJsonTypeTest.cpp:166: undefined reference to
`apache::geode::client::PdxType::PdxType(apache::geode::client::PdxTypeRegistry&,
std::__cxx11::basic_string, std::allocator
> const&, bool)'
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140060#comment-17140060
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442558200
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
Thank to your comment I have realized the assertions are wrong. Thing is
that in the assertions I was using `m_pdxType1.hashcode()` instead of
`std::hash(m_pdxType1)`, that was a change I did right before adding
the commit with the tests to the PR and its causing the compilation to fail in
other place different than the linker error I was asking for. I have just added
the correct code of the assertions.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed
[jira] [Closed] (GEODE-8241) Locator does not observe locator-wait-time
[
https://issues.apache.org/jira/browse/GEODE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey closed GEODE-8241.
> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.14.0
>
>
> In the case where a locator starts up and is unable to connect to any other
> locators, it may decide to become the membership coordinator even if
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There
> should be an additional check for locator-wait-time before becoming
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
> synchronized (viewInstallationLock) {
> becomeCoordinator();
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8241) Locator does not observe locator-wait-time
[
https://issues.apache.org/jira/browse/GEODE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-8241.
--
Fix Version/s: 1.14.0
Resolution: Fixed
> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.14.0
>
>
> In the case where a locator starts up and is unable to connect to any other
> locators, it may decide to become the membership coordinator even if
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There
> should be an additional check for locator-wait-time before becoming
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
> synchronized (viewInstallationLock) {
> becomeCoordinator();
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140058#comment-17140058
]
ASF GitHub Bot commented on GEODE-8212:
---
pivotal-jbarrett commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442553693
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
Oh yeah forgot about that test object. It but me a few times too and
thought it should be renamed. I assumed you tried the fully qualified name on
the line 204 too?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
> Elapsed Time
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140055#comment-17140055
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442548151
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
Thanks for the suggestion, but it did not solve the problem. I used the
fully qualified name in the lines you mention because there is other PdxType
class used in the namespace.
`using PdxTests::PdxType;`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx):
[jira] [Resolved] (GEODE-8237) Add note about 'alter region' and cluster conf service in doc
[ https://issues.apache.org/jira/browse/GEODE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-8237. - Fix Version/s: 1.14.0 Resolution: Fixed > Add note about 'alter region' and cluster conf service in doc > - > > Key: GEODE-8237 > URL: https://issues.apache.org/jira/browse/GEODE-8237 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When cluster configuration service is activated and "alter region" command is > applied on a region that was created via cache.xml, the command fails. > This behavior is ok but it is not documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140054#comment-17140054
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442548151
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
Thanks for the suggestion, but it did not solve the problem. I used the
fully qualified name in the lines you mention because there is other PdxType
class used in the namespace.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
> Elapsed Time
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140053#comment-17140053
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on a change in pull request #619:
URL: https://github.com/apache/geode-native/pull/619#discussion_r442548151
##
File path: cppcache/integration/test/PdxJsonTypeTest.cpp
##
@@ -142,4 +146,91 @@ TEST(PdxJsonTypeTest, testTwoConsecutiveGets) {
std::dynamic_pointer_cast(region2->get("simpleObject")));
}
+TEST(PdxJsonTypeTest, testTwoObjectsWithSameFieldsHaveTheSameHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("REPLICATE")
+.execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_EQ(std::hash(m_pdxType1),std::hash(m_pdxType2));
+}
+
+TEST(PdxJsonTypeTest, testTwoObjectsWithDifferentFieldsHaveDifferentHash) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+ cluster.start();
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("REPLICATE")
+ .execute();
+
+ auto cache = cluster.createCache();
+
+ auto properties = std::make_shared();
+ CacheImpl cacheImpl(, properties, false, false, nullptr);
+
+ PdxTypeRegistry pdxTypeRegistry();
+
+ apache::geode::client::PdxType m_pdxType1(pdxTypeRegistry,
gemfireJsonClassName,false);
+ apache::geode::client::PdxType m_pdxType2(pdxTypeRegistry,
gemfireJsonClassName,false);
+
+ m_pdxType1.addVariableLengthTypeField("bar0", "string",
PdxFieldTypes::STRING);
+ m_pdxType1.addVariableLengthTypeField("bar1", "string",
PdxFieldTypes::STRING);
+
+ m_pdxType2.addVariableLengthTypeField("bar2", "string",
PdxFieldTypes::STRING);
+ m_pdxType2.addVariableLengthTypeField("bar3", "string",
PdxFieldTypes::STRING);
+
+ EXPECT_NE(std::hash(m_pdxType1),std::hash(m_pdxType2));
Review comment:
Thanks for the suggestion, but it did not solve the problem. I used the
fully qualified name in the lines you mention because there is other PdxType
class imported used in the namespace.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
>
[jira] [Commented] (GEODE-8216) SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived FAILED
[
https://issues.apache.org/jira/browse/GEODE-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140040#comment-17140040
]
Mark Hanson commented on GEODE-8216:
Running develop as of a few minutes ago... using this command...
./gradlew geode-wan:repeatDistributedTest -Prepeat=5 -PdunitParallelForks=2
--tests SerialWANPersistenceEnabledGatewaySenderDUnitTest
gets this result...
org.apache.geode.internal.cache.wan.offheap.SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
>
testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$174/1763107236.run
in VM 2 running on Host localhost with 8 VMs
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.wan.WANTestBase that uses int,
intorg.apache.geode.cache.Region Expected region entries: 0 but actual entries:
40 present region keyset [31, 22, 12, 20, 27, 6, 13, 34, 19, 33, 5, 28, 18, 25,
7, 0, 36, 26, 8, 35, 17, 2, 37, 9, 30, 23, 10, 16, 29, 15, 1, 38, 24, 21, 14,
3, 39, 32, 11, 4] expected:<0> but was:<40> within 5 minutes.
Caused by:
java.lang.AssertionError: Expected region entries: 0 but actual
entries: 40 present region keyset [31, 22, 12, 20, 27, 6, 13, 34, 19, 33, 5,
28, 18, 25, 7, 0, 36, 26, 8, 35, 17, 2, 37, 9, 30, 23, 10, 16, 29, 15, 1, 38,
24, 21, 14, 3, 39, 32, 11, 4] expected:<0> but was:<40>
I think this is still not quite perfect.
> SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
>
>
> Key: GEODE-8216
> URL: https://issues.apache.org/jira/browse/GEODE-8216
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Mark Hanson
>Assignee: Mario Ivanac
>Priority: Major
> Labels: ci
> Fix For: 1.14.0
>
> Attachments: geode-8216-logs.tgz
>
>
> Test failure
> {noformat}
> org.apache.geode.internal.cache.wan.offheap.SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> 11:25:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$182/1489068907.run
> in VM 2 running on Host 40c25330a7e0 with 8 VMs
> 11:25:56
> 11:25:56Caused by:
> 11:25:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4] expected:<0>
> but was:<10> within 5 minutes.
> 11:25:56
> 11:25:56Caused by:
> 11:25:56java.lang.AssertionError: Expected region entries: 0 but
> actual entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4]
> expected:<0> but was:<10>
> 11:33:48 {noformat}
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/229]
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-results/distributedTest/1591126795/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-artifacts/1591126795/distributedtestfiles-OpenJDK8-1.14.0-build.0098.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8274) Improve readability of Version comparisons
[
https://issues.apache.org/jira/browse/GEODE-8274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-8274.
--
Fix Version/s: 1.14.0
Resolution: Fixed
> Improve readability of Version comparisons
> --
>
> Key: GEODE-8274
> URL: https://issues.apache.org/jira/browse/GEODE-8274
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently Version comparisons are done with {{Version.compareTo(Version) <=>
> 0}} operations. It is difficult to reason with some of the combinations to
> understand if we are looking for newer or older versions. Convert to some
> natural language style like {{Version.isNewerThan(Version)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8149) Introduce new parameter to control the feature
[ https://issues.apache.org/jira/browse/GEODE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140033#comment-17140033 ] ASF GitHub Bot commented on GEODE-8149: --- pivotal-jbarrett commented on pull request #5139: URL: https://github.com/apache/geode/pull/5139#issuecomment-646339798 @jvarenina How about you close this PR until that is resolved then. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Introduce new parameter to control the feature > -- > > Key: GEODE-8149 > URL: https://issues.apache.org/jira/browse/GEODE-8149 > Project: Geode > Issue Type: Sub-task >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > > * New parameter _security-cn-auth-enabled_ (default value "false") parameter > should be introduced to control this new feature. It should be allowed to set > only if mutual SSL is enabled on all components: _ssl- > ssl-require-authentication == true && ssl-web-require-authentication == true > && ssl-enabled-components==(ALL or all components listed) && > security-manager.isSet == true_ > * New property _security-common-name_ for _security-manager.authentication_ > method should be introduced > * New integration and unit tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8251) exception creating domain.Configuration stops locator startup after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140022#comment-17140022
]
ASF GitHub Bot commented on GEODE-8251:
---
jinmeiliao commented on a change in pull request #5257:
URL: https://github.com/apache/geode/pull/5257#discussion_r442533132
##
File path:
geode-core/src/upgradeTest/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgrade2DUnitTestBase.java
##
@@ -1185,6 +1185,8 @@ Properties getLocatorProperties(String locatorsString,
boolean enableCC) {
props.setProperty(DistributionConfig.LOCATORS_NAME, locatorsString);
props.setProperty(DistributionConfig.LOG_LEVEL_NAME,
DUnitLauncher.logLevel);
props.setProperty(DistributionConfig.ENABLE_CLUSTER_CONFIGURATION_NAME,
enableCC + "");
+// do not start http service to avoid port conflict between upgrade tests
+props.setProperty(DistributionConfig.HTTP_SERVICE_PORT_NAME, "0");
Review comment:
here 0 means do not start.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> exception creating domain.Configuration stops locator startup after rolling
> upgrade
> ---
>
> Key: GEODE-8251
> URL: https://issues.apache.org/jira/browse/GEODE-8251
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI
>
> As reported on the dev@geode mailing list
> https://markmail.org/message/qfnnj2s2x7dzbnzx and shown in the
> {{testRollingUpgradeOfGeodeWithGfs}} test in PR:
> https://github.com/apache/geode/pull/5224, if custom Jars are deployed, the
> locator doesn't start after a rolling upgrade and we see:
> {code}
> org.apache.geode.SerializationException: Could not
> create an instance of
> org.apache.geode.management.internal.configuration.domain.Configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8281) GFSH configure PDX overrides previously set values
[
https://issues.apache.org/jira/browse/GEODE-8281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh updated GEODE-8281:
---
Issue Type: Bug (was: New Feature)
> GFSH configure PDX overrides previously set values
> --
>
> Key: GEODE-8281
> URL: https://issues.apache.org/jira/browse/GEODE-8281
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jason Huynh
>Priority: Major
>
> When configuring pdx using gfsh, if I configure the pdx disk store and then
> the read-serialized on a different command, it overrides the persistent value
> to false.
> {code:java}
> gfsh>configure pdx --disk-store=new-diskstore
> read-serialized = false
> ignore-unread-fields = false
> persistent = true
> disk-store = new-diskstore
> Cluster configuration for group 'cluster' is updated.
> gfsh>configure pdx --read-serialized=true
> read-serialized = true
> ignore-unread-fields = false
> persistent = false
> Cluster configuration for group 'cluster' is updated.{code}
>
> The documentation for this feature also shows the same type of behavior
> (order of operations has been flipped)
> gfsh>configure pdx --read-serialized=true
> persistent = false
> read-serialized = true
> ignore-unread-fields = false
> gfsh>configure pdx --disk-store=/home/username/server4/DEFAULT.drf
> persistent = true
> disk-store = /home/username/server4/DEFAULT.drf
> read-serialized = false
> ignore-unread-fields = false
> Docs for Configure Pdx should probably also be updated when this is fixed and
> also not point to a drf file as the directory.
>
>
> [~nnag] notes that it looks like it has to do with the following
> unspecifiedDefaultValue options
> @CliOption(key = CliStrings.CONFIGURE_PDX__READ__SERIALIZED,
> unspecifiedDefaultValue = "false",
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8282) Creating diskstore with size appened to name doesn't seem to work as documented
[
https://issues.apache.org/jira/browse/GEODE-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh updated GEODE-8282:
---
Issue Type: Bug (was: New Feature)
> Creating diskstore with size appened to name doesn't seem to work as
> documented
> ---
>
> Key: GEODE-8282
> URL: https://issues.apache.org/jira/browse/GEODE-8282
> Project: Geode
> Issue Type: Bug
>Reporter: Jason Huynh
>Priority: Major
>
> The create diskstore --dir option is documented with:
> ...Optionally, directory names may be followed by {{#}} and the maximum
> number of megabytes that the disk store can use in the directory. For example:
> {code:java}
> --dir=/data/ds1
> --dir=/data/ds2#5000
> {code}
> When creating a disk store through gfsh with the size appended, it does not
> appear to limit the size of the directory. There also doesn't seem to be
> much validation...
> for example, when using a negative value we can see that the size described
> does not match what we expected to be our limit.
> {code:java}
> gfsh>describe disk-store --name=diskstore-2#-1000 --member=server1
> Disk Store ID : 643cb4b4-3cb0-40ec-b123-6945b23f165a
> Disk Store Name: diskstore-2#-1000
> Member ID : 192.168.0.3(server1:16006):41001
> Member Name: server1
> Allow Force Compaction : No
> Auto Compaction: Yes
> Compaction Threshold : 50
> Max Oplog Size : 1024
> Queue Size : 0
> Time Interval : 1000
> Write Buffer Size : 32768
> Disk Usage Warning Percentage : 90.0
> Disk Usage Critical Percentage : 99.0
> PDX Serialization Meta-Data Stored : No
> Disk Directory| Size
> --- |
> --
> /Users/jhuynh/apache-geode-1.12.0/bin/server1 | 2147483647
> {code}
> It also appears in code to only affect calculation of disk usage etc, but I
> didn't dig very deep. If it is used there, the negative value will probably
> mess with that calculation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8282) Creating diskstore with size appened to name doesn't seem to work as documented
Jason Huynh created GEODE-8282:
--
Summary: Creating diskstore with size appened to name doesn't seem
to work as documented
Key: GEODE-8282
URL: https://issues.apache.org/jira/browse/GEODE-8282
Project: Geode
Issue Type: New Feature
Reporter: Jason Huynh
The create diskstore --dir option is documented with:
...Optionally, directory names may be followed by {{#}} and the maximum number
of megabytes that the disk store can use in the directory. For example:
{code:java}
--dir=/data/ds1
--dir=/data/ds2#5000
{code}
When creating a disk store through gfsh with the size appended, it does not
appear to limit the size of the directory. There also doesn't seem to be much
validation...
for example, when using a negative value we can see that the size described
does not match what we expected to be our limit.
{code:java}
gfsh>describe disk-store --name=diskstore-2#-1000 --member=server1
Disk Store ID : 643cb4b4-3cb0-40ec-b123-6945b23f165a
Disk Store Name: diskstore-2#-1000
Member ID : 192.168.0.3(server1:16006):41001
Member Name: server1
Allow Force Compaction : No
Auto Compaction: Yes
Compaction Threshold : 50
Max Oplog Size : 1024
Queue Size : 0
Time Interval : 1000
Write Buffer Size : 32768
Disk Usage Warning Percentage : 90.0
Disk Usage Critical Percentage : 99.0
PDX Serialization Meta-Data Stored : No
Disk Directory| Size
--- | --
/Users/jhuynh/apache-geode-1.12.0/bin/server1 | 2147483647
{code}
It also appears in code to only affect calculation of disk usage etc, but I
didn't dig very deep. If it is used there, the negative value will probably
mess with that calculation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8281) GFSH configure PDX overrides previously set values
Jason Huynh created GEODE-8281:
--
Summary: GFSH configure PDX overrides previously set values
Key: GEODE-8281
URL: https://issues.apache.org/jira/browse/GEODE-8281
Project: Geode
Issue Type: New Feature
Components: gfsh
Reporter: Jason Huynh
When configuring pdx using gfsh, if I configure the pdx disk store and then the
read-serialized on a different command, it overrides the persistent value to
false.
{code:java}
gfsh>configure pdx --disk-store=new-diskstore
read-serialized = false
ignore-unread-fields = false
persistent = true
disk-store = new-diskstore
Cluster configuration for group 'cluster' is updated.
gfsh>configure pdx --read-serialized=true
read-serialized = true
ignore-unread-fields = false
persistent = false
Cluster configuration for group 'cluster' is updated.{code}
The documentation for this feature also shows the same type of behavior (order
of operations has been flipped)
gfsh>configure pdx --read-serialized=true
persistent = false
read-serialized = true
ignore-unread-fields = false
gfsh>configure pdx --disk-store=/home/username/server4/DEFAULT.drf
persistent = true
disk-store = /home/username/server4/DEFAULT.drf
read-serialized = false
ignore-unread-fields = false
Docs for Configure Pdx should probably also be updated when this is fixed and
also not point to a drf file as the directory.
[~nnag] notes that it looks like it has to do with the following
unspecifiedDefaultValue options
@CliOption(key = CliStrings.CONFIGURE_PDX__READ__SERIALIZED,
unspecifiedDefaultValue = "false",
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8280) Return correct Redis AUTH errors
[ https://issues.apache.org/jira/browse/GEODE-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140003#comment-17140003 ] ASF GitHub Bot commented on GEODE-8280: --- prettyClouds opened a new pull request #5276: URL: https://github.com/apache/geode/pull/5276 Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Return correct Redis AUTH errors > > > Key: GEODE-8280 > URL: https://issues.apache.org/jira/browse/GEODE-8280 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Murtuza Boxwala >Priority: Major > > Our errors were not matching those of the native redis -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8280) Return correct Auth Error message
[ https://issues.apache.org/jira/browse/GEODE-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala updated GEODE-8280: --- Component/s: redis > Return correct Auth Error message > - > > Key: GEODE-8280 > URL: https://issues.apache.org/jira/browse/GEODE-8280 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Murtuza Boxwala >Priority: Major > > Our errors were not matching those of the native redis -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8280) Return correct Auth Error message
Murtuza Boxwala created GEODE-8280: -- Summary: Return correct Auth Error message Key: GEODE-8280 URL: https://issues.apache.org/jira/browse/GEODE-8280 Project: Geode Issue Type: Improvement Reporter: Murtuza Boxwala Our errors were not matching those of the native redis -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8280) Return correct Redis Auth Error message
[ https://issues.apache.org/jira/browse/GEODE-8280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala updated GEODE-8280: --- Summary: Return correct Redis Auth Error message (was: Return correct Reids Auth Error message) > Return correct Redis Auth Error message > --- > > Key: GEODE-8280 > URL: https://issues.apache.org/jira/browse/GEODE-8280 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Murtuza Boxwala >Priority: Major > > Our errors were not matching those of the native redis -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8228) CI Failure: SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions
[ https://issues.apache.org/jira/browse/GEODE-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-8228: Labels: caching-applications (was: ) > CI Failure: SerialWANStatsDUnitTest > > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions > --- > > Key: GEODE-8228 > URL: https://issues.apache.org/jira/browse/GEODE-8228 > Project: Geode > Issue Type: Test > Components: ci, wan >Reporter: Ernest Burghardt >Priority: Major > Labels: caching-applications > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/247#A] > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-results/distributedTest/1591318846/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Test report artifacts from this job are available at: > > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-artifacts/1591318846/distributedtestfiles-OpenJDK8-1.14.0-build.0115.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8277:
--
Fix Version/s: 1.13.0
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0, 1.14.0
>
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt closed GEODE-8277.
-
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0, 1.14.0
>
>
> Test-only issue.
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8277:
--
Description:
Test-only issue.
At least locator-maeve-keystore.jks is expired. This is causing CI failures now.
All the certs: the CA cert, and each of the three server certs are expired.
These need to all be regenerated using {{CertificateBuilder}} and friends.
I found neither instructions nor a script for regenerating these keystores and
truststores. They may be there but I didn't find 'em.
TODO:
# regenerate signing (CA) cert in truststore.jks
# create the three new keystores containing certs signed by the signing cert
# make sure all the expirations are at least 10 years hence
# make sure there is a README or better: a README and a script for generating
all that
# make sure all the SNI acceptance tests pass locally {{./gradlew
:geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
was:
At least locator-maeve-keystore.jks is expired. This is causing CI failures now.
All the certs: the CA cert, and each of the three server certs are expired.
These need to all be regenerated using {{CertificateBuilder}} and friends.
I found neither instructions nor a script for regenerating these keystores and
truststores. They may be there but I didn't find 'em.
TODO:
# regenerate signing (CA) cert in truststore.jks
# create the three new keystores containing certs signed by the signing cert
# make sure all the expirations are at least 10 years hence
# make sure there is a README or better: a README and a script for generating
all that
# make sure all the SNI acceptance tests pass locally {{./gradlew
:geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0, 1.14.0
>
>
> Test-only issue.
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8277:
--
Component/s: (was: membership)
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.14.0
>
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139997#comment-17139997
]
Xiaojian Zhou commented on GEODE-6489:
--
reproduced in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/287#A
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-6489:
Assignee: Jinmei Liao
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[
https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139994#comment-17139994
]
ASF GitHub Bot commented on GEODE-8272:
---
jinmeiliao commented on a change in pull request #5249:
URL: https://github.com/apache/geode/pull/5249#discussion_r442502008
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/functions/RestoreRedundancyFunction.java
##
@@ -0,0 +1,105 @@
+/*
+ * 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 org.apache.geode.management.internal.functions;
+
+import static
org.apache.geode.management.runtime.RestoreRedundancyResults.Status.ERROR;
+
+import java.util.HashSet;
+import java.util.Set;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.cache.control.RestoreRedundancyOperation;
+import org.apache.geode.cache.execute.FunctionContext;
+import
org.apache.geode.internal.cache.control.SerializableRestoreRedundancyResultsImpl;
+import org.apache.geode.internal.cache.execute.InternalFunction;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+import
org.apache.geode.management.internal.operation.RestoreRedundancyResultsImpl;
+import org.apache.geode.management.operation.RestoreRedundancyRequest;
+
+
+public class RestoreRedundancyFunction implements InternalFunction {
+ private static final Logger logger = LogService.getLogger();
+
+ public static final String ID = RestoreRedundancyFunction.class.getName();
+
+
+ private static final long serialVersionUID = 1L;
+
+ @Override
+ // this would return the RestoreRedundancyResults if successful,
+ // it will return an exception to the caller if status is failure or any
exception happens
+ public void execute(FunctionContext context) {
+Object[] arguments = context.getArguments();
+RestoreRedundancyRequest request = (RestoreRedundancyRequest) arguments[0];
+boolean isStatusCommand = (boolean) arguments[1];
+RestoreRedundancyOperation redundancyOperation =
+
context.getCache().getResourceManager().createRestoreRedundancyOperation();
+Set includeRegionsSet = null;
+if (request.getIncludeRegions() != null) {
+ includeRegionsSet = new HashSet<>(request.getIncludeRegions());
+}
+Set excludeRegionsSet = null;
+if (request.getExcludeRegions() != null) {
+ excludeRegionsSet = new HashSet<>(request.getExcludeRegions());
+}
+redundancyOperation.includeRegions(includeRegionsSet);
+redundancyOperation.excludeRegions(excludeRegionsSet);
+RestoreRedundancyResultsImpl results;
+
+try {
+ if (isStatusCommand) {
+results = (RestoreRedundancyResultsImpl)
redundancyOperation.redundancyStatus();
+ } else {
+
redundancyOperation.shouldReassignPrimaries(request.getReassignPrimaries());
+results = (RestoreRedundancyResultsImpl)
redundancyOperation.start().join();
+ }
+ if (results.getRegionOperationStatus().equals(ERROR)) {
+Exception e = new Exception(results.getRegionOperationMessage());
+throw e;
+ }
+ results.setSuccess(true);
+ results.setStatusMessage("Success"); // MLH change this
+} catch (Exception e) {
+ results =
+ new SerializableRestoreRedundancyResultsImpl();
+ results.setSuccess(false);
+ results.setStatusMessage(e.getMessage());
+}
Review comment:
Generally `SerializableRestoreRedundancyResultsImpl` is used as the data
object that's flowing from server to locator in order to support rolling
upgrade. It would be nice that the result of the function call are all in that
type.
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/functions/RestoreRedundancyFunction.java
##
@@ -0,0 +1,105 @@
+/*
+ * 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
[jira] [Commented] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139992#comment-17139992 ] ASF GitHub Bot commented on GEODE-8272: --- jinmeiliao commented on pull request #5249: URL: https://github.com/apache/geode/pull/5249#issuecomment-646304378 > I have a question about the packages and modules of the classes. e.g. `RestoreRedundancyResultsImpl` is in package `org.apache.geode.management.internal.operation`. And it is in `geode-management` module. Its subclass `SerializableRestoreRedundancyResultsImpl` is in a different package `org.apache.geode.internal.cache.control` and a different module `geode-core`. Why these two classes are in different packages and different modules? > Also some classes have been moved to a different package. e.g. `RegionRedundancyStatus` and `RestoreRedundancyResults`. Is there a reason for that? RestoreRedundancyResults is an interface and is external api, RestoreRedundancyResultsImpl is a direct implementation of it. These two are in the geode-management module because cms needs them to convey result data back to the client. "SerializableRestoreRedundancyResultsImpl", however, is needed to convey function call results from locator to servers, it needs to support rolling upgrade, so it needs to implement "FixedDataSerializableID" interface, that's why we have to have it extends RestoreRedundancyResultsImpl and implement the additional interfaces in geode-core. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8279) ClientSNICQAcceptanceTest.classMethod failed
[
https://issues.apache.org/jira/browse/GEODE-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-8279.
-
Resolution: Duplicate
dupe
> ClientSNICQAcceptanceTest.classMethod failed
>
>
> Key: GEODE-8279
> URL: https://issues.apache.org/jira/browse/GEODE-8279
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
>
> AcceptanceTestOpenJDK11 in CI and the PR pipeline is failing pretty
> frequently.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/275#A]
> {noformat}
> org.apache.geode.client.sni.ClientSNICQAcceptanceTest > classMethod FAILED
> 16:56:41com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter.gfsh' returned exit code 1
> 16:56:41The output was:
> 16:56:411. Executing - start locator --name=locator-maeve --connect=false
> --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> 16:56:41
> 16:56:41
> ..The
> Locator process terminated unexpectedly with exit status 1. Please refer to
> the log file in /locator-maeve for full details.
> 16:56:41
> 16:56:41Exception in thread "main"
> org.apache.geode.SystemConnectException: Problem starting up membership
> services: Unable to form SSL connection. Consult log file for more details
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:189)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
> 16:56:41
> 16:56:41
> 16:56:41
> 16:56:41* Execution Summary
> ***
> 16:56:41Script file: /geode/scripts/geode-starter.gfsh
> 16:56:41
> 16:56:41Command-1 : start locator --name=locator-maeve --connect=false
> --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=/geode/config/gfsecurity.properties
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> 16:56:41Status: FAILED
> 16:56:41at
> com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
> 16:56:41at
> com.palantir.docker.compose.execution.Command.execute(Command.java:50)
> 16:56:41at
> com.palantir.docker.compose.execution.DefaultDockerCompose.exec(DefaultDockerCompose.java:122)
> 16:56:41at
> com.palantir.docker.compose.execution.DelegatingDockerCompose.exec(DelegatingDockerCompose.java:86)
> 16:56:41at
> com.palantir.docker.compose.execution.RetryingDockerCompose.exec(RetryingDockerCompose.java:22)
> 16:56:41at
> com.palantir.docker.compose.DockerComposeRule.exec(DockerComposeRule.java:171)
> 16:56:41at
>
[jira] [Updated] (GEODE-8269) Improve test coverage
[ https://issues.apache.org/jira/browse/GEODE-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8269: --- Description: Analyzed test coverage via Intellij and by looking through all tests. There were some test cases missing, we added some. Others will be added later. Jiras coming soon. (was: Analyzed test coverage via Intellij and by looking through all tests. There were some test cases missing. We either added them or created additional stories in Tracker.) > Improve test coverage > - > > Key: GEODE-8269 > URL: https://issues.apache.org/jira/browse/GEODE-8269 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > > Analyzed test coverage via Intellij and by looking through all tests. There > were some test cases missing, we added some. Others will be added later. > Jiras coming soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8269) Improve test coverage
[ https://issues.apache.org/jira/browse/GEODE-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139964#comment-17139964 ] ASF GitHub Bot commented on GEODE-8269: --- sabbeyPivotal opened a new pull request #5275: URL: https://github.com/apache/geode/pull/5275 Adding some additional tests that were missing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve test coverage > - > > Key: GEODE-8269 > URL: https://issues.apache.org/jira/browse/GEODE-8269 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > > Analyzed test coverage via Intellij and by looking through all tests. There > were some test cases missing, we added some. Others will be added later. > Jiras coming soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139938#comment-17139938
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r442451532
##
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/internal/DSFIDSerializerImpl.java
##
@@ -220,20 +220,6 @@ public void invokeToData(Object ds, DataOutput out) throws
IOException {
}
}
- /**
- * Get the Version of the peer or disk store that created this {@link
DataOutput}.
- * Returns
- * zero if the version is same as this member's.
- */
- public Version getVersionForDataStreamOrNull(DataOutput out) {
-// check if this is a versioned data output
-if (out instanceof VersionedDataStream) {
- return ((VersionedDataStream) out).getVersion();
-} else {
- return null;
-}
- }
Review comment:
dead code
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>
> upgrade from version 1.12 doesn't seem to occur on the Locator
>
> testRollServersOnPartitionedRegion_dataserializable failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139939#comment-17139939
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r442452067
##
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/Version.java
##
@@ -635,48 +569,4 @@ public boolean isPre65() {
.collect(Collectors.toList());
}
- public boolean isCurrentVersion() {
-return this.ordinal == CURRENT.ordinal;
- }
Review comment:
this was used in exactly two places and is better accomplished via
`Version.CURRENT.isEqual(someVersionOrdinal)`
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>
> upgrade from version 1.12 doesn't seem to occur on the Locator
>
> testRollServersOnPartitionedRegion_dataserializable failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8066) Geode should not be using both activation 1.1 and javax.activation 1.2
[ https://issues.apache.org/jira/browse/GEODE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139936#comment-17139936 ] Owen Nichols commented on GEODE-8066: - please do not close, it has NOT been fixed yet. pulse is involved, which you have excluded above. > Geode should not be using both activation 1.1 and javax.activation 1.2 > -- > > Key: GEODE-8066 > URL: https://issues.apache.org/jira/browse/GEODE-8066 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > > javax.activation 1.2 is referenced by Geode as an indirect dependency of jaxb > However, Spring 5.3 brings in some unwanted guests via > com.nimbusds:oauth2-oidc-sdk:7.1.1, including com.sun.mail:javax.mail:1.6.1 > (we already use javax.mail:javax.mail-api:1.6.2) which in turn brings in > javax.activation:activation:1.1 (we already use > com.sun.activation:javax.activation:1.2.0) > It would be nice to only have one version and one provider of mail and > activation in our project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8066) Geode should not be using both activation 1.1 and javax.activation 1.2
[
https://issues.apache.org/jira/browse/GEODE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139933#comment-17139933
]
Robert Houghton edited comment on GEODE-8066 at 6/18/20, 7:15 PM:
--
I looked into this via {noformat}./gradlew geode-core:dependencies
--configuration=runtimeClasspath{noformat} and {noformat}./gradlew
geode-gfsh:dependencies --configuraiton=runtimeClasspath{noformat} and see only
one version of {noformat}javax.mail-api{noformat} or
{noformat}javax.activation{noformat} and
{noformat}javax.activation-api{noformat}. I would like to close this issue.
was (Author: rhoughton):
I looked into this via `./gradlew geode-core:dependencies
--configuration=runtimeClasspath` and `./gradlew geode-gfsh:dependencies
--configuraiton=runtimeClasspath` and see only one version of `javax.mail-api`
or `javax.activation` and `javax.activation-api`. I would like to close this
issue.
> Geode should not be using both activation 1.1 and javax.activation 1.2
> --
>
> Key: GEODE-8066
> URL: https://issues.apache.org/jira/browse/GEODE-8066
> Project: Geode
> Issue Type: Improvement
> Components: pulse
>Reporter: Owen Nichols
>Assignee: Robert Houghton
>Priority: Major
>
> javax.activation 1.2 is referenced by Geode as an indirect dependency of jaxb
> However, Spring 5.3 brings in some unwanted guests via
> com.nimbusds:oauth2-oidc-sdk:7.1.1, including com.sun.mail:javax.mail:1.6.1
> (we already use javax.mail:javax.mail-api:1.6.2) which in turn brings in
> javax.activation:activation:1.1 (we already use
> com.sun.activation:javax.activation:1.2.0)
> It would be nice to only have one version and one provider of mail and
> activation in our project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8066) Geode should not be using both activation 1.1 and javax.activation 1.2
[ https://issues.apache.org/jira/browse/GEODE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139933#comment-17139933 ] Robert Houghton commented on GEODE-8066: I looked into this via `./gradlew geode-core:dependencies --configuration=runtimeClasspath` and `./gradlew geode-gfsh:dependencies --configuraiton=runtimeClasspath` and see only one version of `javax.mail-api` or `javax.activation` and `javax.activation-api`. I would like to close this issue. > Geode should not be using both activation 1.1 and javax.activation 1.2 > -- > > Key: GEODE-8066 > URL: https://issues.apache.org/jira/browse/GEODE-8066 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > > javax.activation 1.2 is referenced by Geode as an indirect dependency of jaxb > However, Spring 5.3 brings in some unwanted guests via > com.nimbusds:oauth2-oidc-sdk:7.1.1, including com.sun.mail:javax.mail:1.6.1 > (we already use javax.mail:javax.mail-api:1.6.2) which in turn brings in > javax.activation:activation:1.1 (we already use > com.sun.activation:javax.activation:1.2.0) > It would be nice to only have one version and one provider of mail and > activation in our project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8216) SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived FAILED
[
https://issues.apache.org/jira/browse/GEODE-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139932#comment-17139932
]
ASF GitHub Bot commented on GEODE-8216:
---
nabarunnag merged pull request #5259:
URL: https://github.com/apache/geode/pull/5259
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
>
>
> Key: GEODE-8216
> URL: https://issues.apache.org/jira/browse/GEODE-8216
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Mark Hanson
>Assignee: Mario Ivanac
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: geode-8216-logs.tgz
>
>
> Test failure
> {noformat}
> org.apache.geode.internal.cache.wan.offheap.SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> 11:25:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$182/1489068907.run
> in VM 2 running on Host 40c25330a7e0 with 8 VMs
> 11:25:56
> 11:25:56Caused by:
> 11:25:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4] expected:<0>
> but was:<10> within 5 minutes.
> 11:25:56
> 11:25:56Caused by:
> 11:25:56java.lang.AssertionError: Expected region entries: 0 but
> actual entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4]
> expected:<0> but was:<10>
> 11:33:48 {noformat}
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/229]
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-results/distributedTest/1591126795/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-artifacts/1591126795/distributedtestfiles-OpenJDK8-1.14.0-build.0098.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8279) ClientSNICQAcceptanceTest.classMethod failed
[
https://issues.apache.org/jira/browse/GEODE-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139927#comment-17139927
]
Mark Hanson commented on GEODE-8279:
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0153/test-results/acceptanceTest/1592506670/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0153/test-artifacts/1592506670/acceptancetestfiles-OpenJDK11-1.14.0-build.0153.tgz
{noformat}
> ClientSNICQAcceptanceTest.classMethod failed
>
>
> Key: GEODE-8279
> URL: https://issues.apache.org/jira/browse/GEODE-8279
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
>
> AcceptanceTestOpenJDK11 in CI and the PR pipeline is failing pretty
> frequently.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/275#A]
> {noformat}
> org.apache.geode.client.sni.ClientSNICQAcceptanceTest > classMethod FAILED
> 16:56:41com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter.gfsh' returned exit code 1
> 16:56:41The output was:
> 16:56:411. Executing - start locator --name=locator-maeve --connect=false
> --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> 16:56:41
> 16:56:41
> ..The
> Locator process terminated unexpectedly with exit status 1. Please refer to
> the log file in /locator-maeve for full details.
> 16:56:41
> 16:56:41Exception in thread "main"
> org.apache.geode.SystemConnectException: Problem starting up membership
> services: Unable to form SSL connection. Consult log file for more details
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:189)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> 16:56:41
> 16:56:41 at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
> 16:56:41
> 16:56:41
> 16:56:41
> 16:56:41* Execution Summary
> ***
> 16:56:41Script file: /geode/scripts/geode-starter.gfsh
> 16:56:41
> 16:56:41Command-1 : start locator --name=locator-maeve --connect=false
> --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=/geode/config/gfsecurity.properties
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> 16:56:41Status: FAILED
> 16:56:41at
> com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
> 16:56:41at
> com.palantir.docker.compose.execution.Command.execute(Command.java:50)
> 16:56:41at
>
[jira] [Updated] (GEODE-8279) ClientSNICQAcceptanceTest.classMethod failed
[
https://issues.apache.org/jira/browse/GEODE-8279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-8279:
---
Description:
AcceptanceTestOpenJDK11 in CI and the PR pipeline is failing pretty frequently.
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/275#A]
{noformat}
org.apache.geode.client.sni.ClientSNICQAcceptanceTest > classMethod FAILED
16:56:41com.palantir.docker.compose.execution.DockerExecutionException:
'docker-compose exec -T geode gfsh run
--file=/geode/scripts/geode-starter.gfsh' returned exit code 1
16:56:41The output was:
16:56:411. Executing - start locator --name=locator-maeve --connect=false
--hostname-for-clients=locator-maeve
--properties-file=/geode/config/gemfire.properties
--security-properties-file=
--J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
16:56:41
16:56:41
..The
Locator process terminated unexpectedly with exit status 1. Please refer to
the log file in /locator-maeve for full details.
16:56:41
16:56:41Exception in thread "main" org.apache.geode.SystemConnectException:
Problem starting up membership services: Unable to form SSL connection.
Consult log file for more details
16:56:41
16:56:41at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:189)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
16:56:41
16:56:41at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
16:56:41
16:56:41at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
16:56:41
16:56:41at
org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
16:56:41
16:56:41at
org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
16:56:41
16:56:41
16:56:41
16:56:41* Execution Summary ***
16:56:41Script file: /geode/scripts/geode-starter.gfsh
16:56:41
16:56:41Command-1 : start locator --name=locator-maeve --connect=false
--hostname-for-clients=locator-maeve
--properties-file=/geode/config/gemfire.properties
--security-properties-file=/geode/config/gfsecurity.properties
--J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
16:56:41Status: FAILED
16:56:41at
com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
16:56:41at
com.palantir.docker.compose.execution.Command.execute(Command.java:50)
16:56:41at
com.palantir.docker.compose.execution.DefaultDockerCompose.exec(DefaultDockerCompose.java:122)
16:56:41at
com.palantir.docker.compose.execution.DelegatingDockerCompose.exec(DelegatingDockerCompose.java:86)
16:56:41at
com.palantir.docker.compose.execution.RetryingDockerCompose.exec(RetryingDockerCompose.java:22)
16:56:41at
com.palantir.docker.compose.DockerComposeRule.exec(DockerComposeRule.java:171)
16:56:41at
org.apache.geode.client.sni.ClientSNICQAcceptanceTest.beforeClass(ClientSNICQAcceptanceTest.java:113)
16:56:41
16:56:41org.apache.geode.client.sni.ClientSNICQAcceptanceTest > classMethod
FAILED
16:56:41com.palantir.docker.compose.execution.DockerExecutionException:
'docker-compose exec -T geode cat server-dolores/server-dolores.log' returned
exit code 1
16:56:41The output was:
16:56:41cat: server-dolores/server-dolores.log: No such file or directory
16:56:41at
com.palantir.docker.compose.execution.Command.lambda$throwingOnError$12(Command.java:60)
16:56:41at
[jira] [Created] (GEODE-8279) ClientSNICQAcceptanceTest.classMethod failed
Mark Hanson created GEODE-8279:
--
Summary: ClientSNICQAcceptanceTest.classMethod failed
Key: GEODE-8279
URL: https://issues.apache.org/jira/browse/GEODE-8279
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: Mark Hanson
{noformat}
org.apache.geode.client.sni.ClientSNICQAcceptanceTest > classMethod FAILED
16:04:19
com.palantir.docker.compose.execution.DockerExecutionException:
'docker-compose exec -T geode gfsh run
--file=/geode/scripts/geode-starter.gfsh' returned exit code 1
16:04:19
The output was:
16:04:19
1. Executing - start locator --name=locator-maeve --connect=false
--hostname-for-clients=locator-maeve
--properties-file=/geode/config/gemfire.properties
--security-properties-file=
--J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
16:04:1916:04:19
.The
Locator process terminated unexpectedly with exit status 1. Please refer to
the log file in /locator-maeve for full details.
16:04:1916:04:19
Exception in thread "main" org.apache.geode.SystemConnectException: Problem
starting up membership services: Unable to form SSL connection. Consult log
file for more details
16:04:1916:04:19
at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:189)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
16:04:1916:04:19
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
16:04:1916:04:19
at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
16:04:1916:04:19
at
org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
16:04:1916:04:19
at
org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
16:04:1916:04:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8066) Geode should not be using both activation 1.1 and javax.activation 1.2
[ https://issues.apache.org/jira/browse/GEODE-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton reassigned GEODE-8066: -- Assignee: Robert Houghton > Geode should not be using both activation 1.1 and javax.activation 1.2 > -- > > Key: GEODE-8066 > URL: https://issues.apache.org/jira/browse/GEODE-8066 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > > javax.activation 1.2 is referenced by Geode as an indirect dependency of jaxb > However, Spring 5.3 brings in some unwanted guests via > com.nimbusds:oauth2-oidc-sdk:7.1.1, including com.sun.mail:javax.mail:1.6.1 > (we already use javax.mail:javax.mail-api:1.6.2) which in turn brings in > javax.activation:activation:1.1 (we already use > com.sun.activation:javax.activation:1.2.0) > It would be nice to only have one version and one provider of mail and > activation in our project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[
https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139904#comment-17139904
]
ASF GitHub Bot commented on GEODE-8272:
---
jinmeiliao commented on a change in pull request #5249:
URL: https://github.com/apache/geode/pull/5249#discussion_r442418701
##
File path:
geode-management/src/main/java/org/apache/geode/management/operation/RestoreRedundancyRequest.java
##
@@ -0,0 +1,123 @@
+/*
+ * 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 org.apache.geode.management.operation;
+
+import java.util.List;
+
+import com.fasterxml.jackson.annotation.JsonIgnore;
+
+import org.apache.geode.annotations.Experimental;
+import org.apache.geode.management.api.ClusterManagementOperation;
+import org.apache.geode.management.runtime.RestoreRedundancyResults;
+
+/**
+ * Defines a distributed system request to optimize bucket allocation across
members.
+ */
+@Experimental
+public class RestoreRedundancyRequest
+implements ClusterManagementOperation {
+
+ /**
+ * see {@link #getEndpoint()}
+ */
+ public static final String RESTORE_REDUNDANCY_REBALANCE_ENDPOINT =
+ "/operations/restoreRedundancy";
+ // null means all regions included
+ private List includeRegions;
+ // null means don't exclude any regions
+ private List excludeRegions;
+ private boolean reassignPrimaries = true;
+ private String operator;
+
+ /**
+ * by default, requests all partitioned regions to be rebalanced
+ */
+ public RestoreRedundancyRequest() {}
+
+ /**
+ * copy constructor
+ */
+ public RestoreRedundancyRequest(
+ RestoreRedundancyRequest other) {
+this.setExcludeRegions(other.getExcludeRegions());
+this.setIncludeRegions(other.getIncludeRegions());
+this.setReassignPrimaries(other.getReassignPrimaries());
+this.operator = other.getOperator();
+ }
+
+ /***
+ * Returns the list of regions to be rebalanced (or an empty list for
all-except-excluded)
+ */
+ public List getIncludeRegions() {
+return includeRegions;
+ }
+
+ /**
+ * requests rebalance of the specified region(s) only. When at least one
region is specified, this
+ * takes precedence over any excluded regions.
+ */
+ public void setIncludeRegions(List includeRegions) {
+this.includeRegions = includeRegions;
+ }
+
+ /***
+ * Returns the list of regions NOT to be rebalanced (iff {@link
#getIncludeRegions()} is empty)
+ */
+ public List getExcludeRegions() {
+return excludeRegions;
+ }
+
+ /**
+ * excludes specific regions from the rebalance, if {@link
#getIncludeRegions()} is empty,
+ * otherwise has no effect
+ * default: no regions are excluded
+ */
+ public void setExcludeRegions(List excludeRegions) {
+this.excludeRegions = excludeRegions;
+ }
+
+ public void setReassignPrimaries(boolean reassignPrimaries) {
+this.reassignPrimaries = reassignPrimaries;
+ }
+
+ public boolean getReassignPrimaries() {
+return reassignPrimaries;
+ }
+
+ @Override
+ @JsonIgnore
+ public String getEndpoint() {
+return RESTORE_REDUNDANCY_REBALANCE_ENDPOINT;
+ }
+
+ @Override
+ public String getOperator() {
+return operator;
+ }
+
+ public void setOperator(String operator) {
Review comment:
I believe you will need to set the operator in the controller, just like
what the rebalance did
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Refactor GFSH Restore Redundancy Command code to allow for REST API
> ---
>
> Key: GEODE-8272
> URL: https://issues.apache.org/jira/browse/GEODE-8272
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
>
> Refactor GFSH Restore Redundancy Command code to allow for
[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time
[
https://issues.apache.org/jira/browse/GEODE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139894#comment-17139894
]
ASF GitHub Bot commented on GEODE-8241:
---
aaronlindsey commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-646223094
I rebased on develop to pick up the fix for the failing
`AcceptanceTestOpenJDK11` check.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other
> locators, it may decide to become the membership coordinator even if
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There
> should be an additional check for locator-wait-time before becoming
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
> synchronized (viewInstallationLock) {
> becomeCoordinator();
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time
[
https://issues.apache.org/jira/browse/GEODE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139887#comment-17139887
]
ASF GitHub Bot commented on GEODE-8241:
---
aaronlindsey commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-646219134
The failing `AcceptanceTestOpenJDK11` check is also failing on develop.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other
> locators, it may decide to become the membership coordinator even if
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There
> should be an additional check for locator-wait-time before becoming
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
> synchronized (viewInstallationLock) {
> becomeCoordinator();
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8251) exception creating domain.Configuration stops locator startup after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139884#comment-17139884
]
ASF GitHub Bot commented on GEODE-8251:
---
kirklund commented on a change in pull request #5257:
URL: https://github.com/apache/geode/pull/5257#discussion_r442402889
##
File path:
geode-management/src/main/java/org/apache/geode/management/configuration/AbstractConfiguration.java
##
@@ -47,7 +47,7 @@
@Experimental
public abstract class AbstractConfiguration
implements Identifiable, JsonSerializable {
-
+ private static final long serialVersionUID = -6612840641128145954L;
Review comment:
Optional: all JDK classes put serialVersionUID at the bottom of the
class. I usually do this to try and be consistent but obviously doesn't matter
much.
##
File path:
geode-core/src/upgradeTest/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeWithGfshDUnitTest.java
##
@@ -0,0 +1,160 @@
+/*
+ * 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 org.apache.geode.internal.cache.rollingupgrade;
+
+/*
+ * 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.
+ */
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.io.File;
+import java.io.IOException;
+import java.util.Collection;
+import java.util.List;
+
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.rules.TemporaryFolder;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+
+import org.apache.geode.internal.UniquePortSupplier;
+import org.apache.geode.test.compiler.ClassBuilder;
+import org.apache.geode.test.junit.categories.BackwardCompatibilityTest;
+import org.apache.geode.test.junit.rules.gfsh.GfshExecution;
+import org.apache.geode.test.junit.rules.gfsh.GfshRule;
+import org.apache.geode.test.junit.rules.gfsh.GfshScript;
+import
org.apache.geode.test.junit.runners.CategoryWithParameterizedRunnerFactory;
+import org.apache.geode.test.version.TestVersion;
+import org.apache.geode.test.version.VersionManager;
+
+/**
+ * This test iterates through the versions of Geode and executes client
compatibility with
+ * the current version of Geode.
+ */
+@Category({BackwardCompatibilityTest.class})
+@RunWith(Parameterized.class)
+@Parameterized.UseParametersRunnerFactory(CategoryWithParameterizedRunnerFactory.class)
+public class RollingUpgradeWithGfshDUnitTest {
+ private final UniquePortSupplier portSupplier = new UniquePortSupplier();
+ private final String oldVersion;
+
+ @Parameterized.Parameters(name = "{0}")
+ public static Collection data() {
+List result =
VersionManager.getInstance().getVersionsWithoutCurrent();
+result.removeIf(s -> TestVersion.compare(s, "1.10.0") < 0);
+return result;
+ }
+
+ @Rule
+ public GfshRule oldGfsh;
+
+ @Rule
+ public GfshRule currentGfsh = new GfshRule();
+
+ @Rule
+ public TemporaryFolder tempFolder = new TemporaryFolder();
+
+ public RollingUpgradeWithGfshDUnitTest(String version) {
+oldVersion = version;
+oldGfsh = new GfshRule(oldVersion);
+ }
+
+ @Test
+ public void testRollingUpgradeWithDeployment() throws Exception {
+int locatorPort = portSupplier.getAvailablePort();
+int locatorJmxPort = portSupplier.getAvailablePort();
+int locator2Port = portSupplier.getAvailablePort();
+int locator2JmxPort =
[jira] [Resolved] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8277.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.14.0
>
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8276) KEYS command returns corrupted keys in some cases
[ https://issues.apache.org/jira/browse/GEODE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139881#comment-17139881 ] ASF GitHub Bot commented on GEODE-8276: --- jdeppe-pivotal merged pull request #5272: URL: https://github.com/apache/geode/pull/5272 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > KEYS command returns corrupted keys in some cases > - > > Key: GEODE-8276 > URL: https://issues.apache.org/jira/browse/GEODE-8276 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > In some cases the keys returned by the KEYS command will be corrupted. If the > key that is stored contains bytes that when UTF-8 encoded produce multiple > bytes then that key will be corrupted when returned from the KEYS command. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139879#comment-17139879
]
ASF GitHub Bot commented on GEODE-8277:
---
bschuchardt merged pull request #5274:
URL: https://github.com/apache/geode/pull/5274
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8237) Add note about 'alter region' and cluster conf service in doc
[ https://issues.apache.org/jira/browse/GEODE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139872#comment-17139872 ] ASF GitHub Bot commented on GEODE-8237: --- jinmeiliao merged pull request #5231: URL: https://github.com/apache/geode/pull/5231 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add note about 'alter region' and cluster conf service in doc > - > > Key: GEODE-8237 > URL: https://issues.apache.org/jira/browse/GEODE-8237 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > When cluster configuration service is activated and "alter region" command is > applied on a region that was created via cache.xml, the command fails. > This behavior is ok but it is not documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8250) Improve documentation for logging
[
https://issues.apache.org/jira/browse/GEODE-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139871#comment-17139871
]
ASF GitHub Bot commented on GEODE-8250:
---
jinmeiliao commented on a change in pull request #5268:
URL: https://github.com/apache/geode/pull/5268#discussion_r442387862
##
File path:
geode-assembly/src/acceptanceTest/java/org/apache/geode/logging/LocatorWithCustomLogConfigAcceptanceTest.java
##
@@ -0,0 +1,291 @@
+/*
+ * 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 org.apache.geode.logging;
+
+import static java.nio.file.Files.copy;
+import static
org.apache.geode.internal.AvailablePortHelper.getRandomAvailableTCPPorts;
+import static org.apache.geode.test.assertj.LogFileAssert.assertThat;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.util.ResourceUtils.createFileFromResource;
+import static org.apache.geode.test.util.ResourceUtils.getResource;
+
+import java.nio.file.Path;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+import org.junit.rules.TestName;
+
+import org.apache.geode.test.junit.rules.RequiresGeodeHome;
+import org.apache.geode.test.junit.rules.gfsh.GfshRule;
+
+public class LocatorWithCustomLogConfigAcceptanceTest {
+
+ private static final String CONFIG_WITH_GEODE_PLUGINS_FILE_NAME =
+ "LocatorWithCustomLogConfigAcceptanceTestWithGeodePlugins.xml";
+ private static final String CONFIG_WITHOUT_GEODE_PLUGINS_FILE_NAME =
+ "LocatorWithCustomLogConfigAcceptanceTestWithoutGeodePlugins.xml";
+
+ private String locatorName;
+ private Path workingDir;
+ private int locatorPort;
+ private int httpPort;
+ private int rmiPort;
+ private Path configWithGeodePluginsFile;
+ private Path configWithoutGeodePluginsFile;
+ private Path locatorLogFile;
+ private Path pulseLogFile;
+ private Path customLogFile;
+
+ @Rule
+ public GfshRule gfshRule = new GfshRule();
+ @Rule
+ public RequiresGeodeHome requiresGeodeHome = new RequiresGeodeHome();
+ @Rule
+ public TemporaryFolder temporaryFolder = new TemporaryFolder();
+ @Rule
+ public TestName testName = new TestName();
+
+ @Before
+ public void setUpLogConfigFiles() {
+configWithGeodePluginsFile = createFileFromResource(
+getResource(CONFIG_WITH_GEODE_PLUGINS_FILE_NAME),
temporaryFolder.getRoot(),
+CONFIG_WITH_GEODE_PLUGINS_FILE_NAME)
+.toPath();
+
+configWithoutGeodePluginsFile = createFileFromResource(
+getResource(CONFIG_WITHOUT_GEODE_PLUGINS_FILE_NAME),
temporaryFolder.getRoot(),
+CONFIG_WITHOUT_GEODE_PLUGINS_FILE_NAME)
+.toPath();
+ }
+
+ @Before
+ public void setUpOutputFiles() {
+locatorName = testName.getMethodName();
+
+workingDir = temporaryFolder.getRoot().toPath().toAbsolutePath();
+locatorLogFile = workingDir.resolve(locatorName + ".log");
+pulseLogFile = workingDir.resolve("pulse.log");
+customLogFile = workingDir.resolve("custom.log");
+ }
+
+ @Before
+ public void setUpRandomPorts() {
+int[] ports = getRandomAvailableTCPPorts(3);
+
+locatorPort = ports[0];
+httpPort = ports[1];
+rmiPort = ports[2];
+ }
+
+ @After
+ public void stopLocator() {
+gfshRule.execute("stop locator --dir=" + workingDir);
Review comment:
GfshRule itself will try to stop all the processes it starts using the
rule if you allow it to host the working dir of all the servers/locators it
started. Using the gfshRule.getWorkingDir will get the temp folder that gfsh
uses and all the servers/locators' working dir will be under there. That way,
when tests finish, GfshRule will kill all the members automatically.
##
File path:
geode-assembly/src/acceptanceTest/java/org/apache/geode/logging/LocatorWithCustomLogConfigAcceptanceTest.java
##
@@ -0,0 +1,291 @@
+/*
+ * 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
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139566#comment-17139566
]
ASF GitHub Bot commented on GEODE-8212:
---
pdxcodemonkey commented on pull request #619:
URL: https://github.com/apache/geode-native/pull/619#issuecomment-646187772
Sure, I'll have a look
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
> Elapsed Time (serializePdx): 0.006325 milliseconds
> Elapsed Time (serializePdx): 0.005419 milliseconds
> Elapsed Time (serializePdx): 0.005266 milliseconds
> Elapsed Time (serializePdx): 0.005662 milliseconds
> Elapsed Time (serializePdx): 0.005407 milliseconds
> Elapsed Time (serializePdx): 0.005286 milliseconds
> Elapsed Time (serializePdx): 0.005467 milliseconds
> Elapsed Time (serializePdx): 0.005276 milliseconds
> Elapsed Time (serializePdx): 0.005298 milliseconds
> {noformat}
> And after creating 50.000 instances, these are the times for the last 10
> calls with the current "<" operator and with the old one respectively::
> {noformat}
> Elapsed Time (serializePdx): 8.11767 milliseconds
> Elapsed Time (serializePdx): 8.15727 milliseconds
> Elapsed Time (serializePdx): 8.09303 milliseconds
> Elapsed Time (serializePdx): 7.89909 milliseconds
> Elapsed Time (serializePdx): 8.37956 milliseconds
> Elapsed Time (serializePdx): 8.21303 milliseconds
> Elapsed Time (serializePdx): 8.14189 milliseconds
> Elapsed Time (serializePdx): 8.21266 milliseconds
> Elapsed Time (serializePdx): 8.21683 milliseconds
> Elapsed Time (serializePdx): 7.78765 milliseconds
> {noformat}
> {noformat}
> Elapsed Time (serializePdx): 0.003014 milliseconds
> Elapsed Time (serializePdx): 0.003 milliseconds
> Elapsed Time (serializePdx): 0.003084 milliseconds
> Elapsed Time (serializePdx): 0.003112 milliseconds
> Elapsed Time (serializePdx): 0.00305 milliseconds
> Elapsed Time (serializePdx): 0.003018 milliseconds
> Elapsed Time (serializePdx): 0.003029 milliseconds
> Elapsed Time (serializePdx): 0.003061 milliseconds
> Elapsed Time (serializePdx): 0.003043 milliseconds
> Elapsed Time (serializePdx): 0.003086 milliseconds
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8212) Change in PdxType class "<" operator impacts performance
[
https://issues.apache.org/jira/browse/GEODE-8212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139562#comment-17139562
]
ASF GitHub Bot commented on GEODE-8212:
---
alb3rtobr commented on pull request #619:
URL: https://github.com/apache/geode-native/pull/619#issuecomment-646185173
Could you help me with the tests? I have not been able to compile them,
there is a linker error saying there is an undefined reference to `PdxType` but
I dont know how to change the cmake config to fix it. Thanks in advance!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change in PdxType class "<" operator impacts performance
>
>
> Key: GEODE-8212
> URL: https://issues.apache.org/jira/browse/GEODE-8212
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Attachments: performance_after_GEODE-7694.patch
>
>
> While investigating a performance problem of the C++ native client, it has
> been observed that change in the PdxType class "<" operator introduced by
> GEODE-7694 impacts performance of PdxHelper::serializePdx().
> Im attaching a patch with some code and a test case I have used to benchmark
> that method. With the current implementation in develop branch, creating just
> 10 instances is enough to see the difference. The calls to serializePdx take
> these times:
> {noformat}
> Elapsed Time (serializePdx): 32.1322 milliseconds
> Elapsed Time (serializePdx): 3.06044 milliseconds
> Elapsed Time (serializePdx): 1.58791 milliseconds
> Elapsed Time (serializePdx): 1.62466 milliseconds
> Elapsed Time (serializePdx): 1.53676 milliseconds
> Elapsed Time (serializePdx): 1.59278 milliseconds
> Elapsed Time (serializePdx): 1.82878 milliseconds
> Elapsed Time (serializePdx): 1.36811 milliseconds
> Elapsed Time (serializePdx): 1.6956 milliseconds
> Elapsed Time (serializePdx): 1.46873 milliseconds
> Elapsed Time (serializePdx): 1.53206 milliseconds
> {noformat}
> While these are the times using the old "<" operator:
> {noformat}
> Elapsed Time (serializePdx): 56.1524 milliseconds
> Elapsed Time (serializePdx): 0.012327 milliseconds
> Elapsed Time (serializePdx): 0.006325 milliseconds
> Elapsed Time (serializePdx): 0.005419 milliseconds
> Elapsed Time (serializePdx): 0.005266 milliseconds
> Elapsed Time (serializePdx): 0.005662 milliseconds
> Elapsed Time (serializePdx): 0.005407 milliseconds
> Elapsed Time (serializePdx): 0.005286 milliseconds
> Elapsed Time (serializePdx): 0.005467 milliseconds
> Elapsed Time (serializePdx): 0.005276 milliseconds
> Elapsed Time (serializePdx): 0.005298 milliseconds
> {noformat}
> And after creating 50.000 instances, these are the times for the last 10
> calls with the current "<" operator and with the old one respectively::
> {noformat}
> Elapsed Time (serializePdx): 8.11767 milliseconds
> Elapsed Time (serializePdx): 8.15727 milliseconds
> Elapsed Time (serializePdx): 8.09303 milliseconds
> Elapsed Time (serializePdx): 7.89909 milliseconds
> Elapsed Time (serializePdx): 8.37956 milliseconds
> Elapsed Time (serializePdx): 8.21303 milliseconds
> Elapsed Time (serializePdx): 8.14189 milliseconds
> Elapsed Time (serializePdx): 8.21266 milliseconds
> Elapsed Time (serializePdx): 8.21683 milliseconds
> Elapsed Time (serializePdx): 7.78765 milliseconds
> {noformat}
> {noformat}
> Elapsed Time (serializePdx): 0.003014 milliseconds
> Elapsed Time (serializePdx): 0.003 milliseconds
> Elapsed Time (serializePdx): 0.003084 milliseconds
> Elapsed Time (serializePdx): 0.003112 milliseconds
> Elapsed Time (serializePdx): 0.00305 milliseconds
> Elapsed Time (serializePdx): 0.003018 milliseconds
> Elapsed Time (serializePdx): 0.003029 milliseconds
> Elapsed Time (serializePdx): 0.003061 milliseconds
> Elapsed Time (serializePdx): 0.003043 milliseconds
> Elapsed Time (serializePdx): 0.003086 milliseconds
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8278) Gateway sender queues using heap memory way above configured value after server restart
[ https://issues.apache.org/jira/browse/GEODE-8278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-8278: - Description: In a Geode system with the following characteristics: * WAN replication * partition redundant regions * overflow configured for the gateway senders queues by means of persistence and maximum queue memory set. * gateway receivers stopped in one site (B) * Operations sent to the site that does not have the gateway receivers stopped (A) When operations are sent to site A, the gateway sender queues start to grow as expected and the heap memory consumed by the queues does not grow indefinitely given that there is overflow to disk when the limit is reached. But, if a server is restarted, the restarted server will show a much higher heap memory used than the memory used by this server before it was restarted or by the other servers. This can even provoke that the server cannot be restarted if the heap memory it requires is above the limit configured. According to the memory analyzer the entries taking up the memory are subclasses of VMThinDiskLRURegionEntryHeap. The number of instances of this type are the same in the restarted server than in the not restarted servers but on the restarted server they take much more memory. The reason seems to be that they hold references to previousEvictionNode and nextEvictionNode. If redundancy is not configured for the region then the problem is not manifested, i.e. the heap memory used by the restarted server is similar to the one prior to the restart. was: In a Geode system with the following characteristics: * WAN replication * partition redundant regions * overflow configured for the gateway senders queues by means of persistence and maximum queue memory set. * gateway receivers stopped in one site (B) * Operations sent to the site that does not have the gateway receivers stopped (A) When operations are sent to site A, the gateway sender queues start to grow as expected and the heap memory consumed by the queues does not grow indefinitely given that there is overflow to disk when the limit is reached. But, if a server is restarted, the restarted server will show a much higher heap memory used than the memory used by this server before it was restarted or by the other servers. This can even provoke that the server cannot be restarted if the heap memory it requires is above the limit configured. According to the memory analyzer the entries taking up the memory are subclasses of VMThinDiskLRURegionEntryHeap. The number of instances of this type are the same in the restarted server than in the not restarted servers but on the restarted server they take much more memory. The reason seems to be that they hold references to previousEvictionNode and nextEvictionNode. > Gateway sender queues using heap memory way above configured value after > server restart > --- > > Key: GEODE-8278 > URL: https://issues.apache.org/jira/browse/GEODE-8278 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > In a Geode system with the following characteristics: > * WAN replication > * partition redundant regions > * overflow configured for the gateway senders queues by means of persistence > and maximum queue memory set. > * gateway receivers stopped in one site (B) > * Operations sent to the site that does not have the gateway receivers > stopped (A) > When operations are sent to site A, the gateway sender queues start to grow > as expected and the heap memory consumed by the queues does not grow > indefinitely given that there is overflow to disk when the limit is reached. > But, if a server is restarted, the restarted server will show a much higher > heap memory used than the memory used by this server before it was restarted > or by the other servers. > This can even provoke that the server cannot be restarted if the heap memory > it requires is above the limit configured. > According to the memory analyzer the entries taking up the memory are > subclasses of VMThinDiskLRURegionEntryHeap. > The number of instances of this type are the same in the restarted server > than in the not restarted servers but on the restarted server they take much > more memory. The reason seems to be that they hold references to > previousEvictionNode and nextEvictionNode. > If redundancy is not configured for the region then the problem is not > manifested, i.e. the heap memory used by the restarted server is similar to > the one prior to the restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8277:
--
Component/s: membership
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8277) acceptance test certificates expired in Dockerized SNI acceptance tests
[
https://issues.apache.org/jira/browse/GEODE-8277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139513#comment-17139513
]
ASF GitHub Bot commented on GEODE-8277:
---
bschuchardt opened a new pull request #5274:
URL: https://github.com/apache/geode/pull/5274
The old keystores have expired. I've generated 100 year keystores and added
a
program to recreate them if necessary.
I've inspected the new jks files to verify that they expire in 2120 and have
run the SNI tests to ensure that they still work.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> acceptance test certificates expired in Dockerized SNI acceptance tests
> ---
>
> Key: GEODE-8277
> URL: https://issues.apache.org/jira/browse/GEODE-8277
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> At least locator-maeve-keystore.jks is expired. This is causing CI failures
> now.
> All the certs: the CA cert, and each of the three server certs are expired.
> These need to all be regenerated using {{CertificateBuilder}} and friends.
> I found neither instructions nor a script for regenerating these keystores
> and truststores. They may be there but I didn't find 'em.
> TODO:
> # regenerate signing (CA) cert in truststore.jks
> # create the three new keystores containing certs signed by the signing cert
> # make sure all the expirations are at least 10 years hence
> # make sure there is a README or better: a README and a script for generating
> all that
> # make sure all the SNI acceptance tests pass locally {{./gradlew
> :geode-assembly:acceptanceTest --tests=org.apache.geode.client.sni.*}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8269) Improve test coverage
[ https://issues.apache.org/jira/browse/GEODE-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139510#comment-17139510 ] ASF GitHub Bot commented on GEODE-8269: --- sabbeyPivotal commented on pull request #5262: URL: https://github.com/apache/geode/pull/5262#issuecomment-646107055 AcceptanceTestOpenJDK11 failure is not a result of these code changes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve test coverage > - > > Key: GEODE-8269 > URL: https://issues.apache.org/jira/browse/GEODE-8269 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > > Analyzed test coverage via Intellij and by looking through all tests. There > were some test cases missing. We either added them or created additional > stories in Tracker. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8278) Gateway sender queues using up a lot of heap space after server restart
Alberto Gomez created GEODE-8278: Summary: Gateway sender queues using up a lot of heap space after server restart Key: GEODE-8278 URL: https://issues.apache.org/jira/browse/GEODE-8278 Project: Geode Issue Type: Bug Components: eviction Reporter: Alberto Gomez In a Geode system with the following characteristics: * WAN replication * partition redundant regions * overflow configured for the gateway senders queues by means of persistence and maximum queue memory set. * gateway receivers stopped in one site (B) * Operations sent to the site that does not have the gateway receivers stopped (A) When operations are sent to site A, the gateway sender queues start to grow as expected and the heap memory consumed by the queues does not grow indefinitely given that there is overflow to disk when the limit is reached. But, if a server is restarted, the restarted server will show a much higher heap memory used than the memory used by this server before it was restarted or by the other servers. This can even provoke that the server cannot be restarted if the heap memory it requires is above the limit configured. According to the memory analyzer the entries taking up the memory are subclasses of VMThinDiskLRURegionEntryHeap. The number of instances of this type are the same in the restarted server than in the not restarted servers but on the restarted server they take much more memory. The reason seems to be that they hold references to previousEvictionNode and nextEvictionNode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139467#comment-17139467
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill opened a new pull request #5273:
URL: https://github.com/apache/geode/pull/5273
[GEODE-8240](https://issues.apache.org/jira/browse/GEODE-8240)
This is an alternative solution to the one explored in
https://github.com/apache/geode/pull/5269. This PR introduces a new interface
`VersionOrdinal` to model not just versions we know about (as `Version` does)
but also future versions. Formerly Geode modeled these as `short` but that
presented difficulties in the many places where we need to compare versions. By
unifying known and unknown versions under one interface, capable of providing
generic comparison (`compareTo()`, `equals()`, and `hashCode()`) my hope is
that we can eliminate this egregious loss of information (in that other PR's
`Version` implementation):
```java
@Override
public Version getVersion() {
public Version getVersion() {
return versionObj;
try {
return Version.fromOrdinal(versionOrdinal);
} catch (final UnsupportedSerializationVersionException e) {
return Version.CURRENT;
}
```
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>
> upgrade from version 1.12 doesn't seem to occur on the Locator
>
> testRollServersOnPartitionedRegion_dataserializable failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8241) Locator does not observe locator-wait-time
[
https://issues.apache.org/jira/browse/GEODE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139449#comment-17139449
]
ASF GitHub Bot commented on GEODE-8241:
---
aaronlindsey commented on pull request #5236:
URL: https://github.com/apache/geode/pull/5236#issuecomment-646043919
@Bill @bschuchardt with the previous changes I noticed a failure after
400-something runs. The chosen `locatorWaitTime` was not quite long enough. So
I greatly increased the `locatorWaitTime` in the latest commit and then I was
able to run the test 1000x successfully. I'm pretty confident that after the
latest commit the chance of flakiness is negligible.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locator does not observe locator-wait-time
> --
>
> Key: GEODE-8241
> URL: https://issues.apache.org/jira/browse/GEODE-8241
> Project: Geode
> Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>
> In the case where a locator starts up and is unable to connect to any other
> locators, it may decide to become the membership coordinator even if
> locator-wait-time has not elapsed.
> The following conditional from GMSJoinLeave.java causes the issue. There
> should be an additional check for locator-wait-time before becoming
> coordinator.
> {code:java}
> if (state.joinedMembersContacted <= 0 &&
> (tries >= minimumRetriesBeforeBecomingCoordinator ||
> state.locatorsContacted >= locators.size())) {
> synchronized (viewInstallationLock) {
> becomeCoordinator();
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139436#comment-17139436
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5269:
URL: https://github.com/apache/geode/pull/5269#discussion_r442241602
##
File path:
geode-membership/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberData.java
##
@@ -220,12 +220,16 @@ public InetAddress getInetAddress() {
@Override
public short getVersionOrdinal() {
-return this.versionObj.ordinal();
+return versionOrdinal;
}
@Override
public Version getVersion() {
-return versionObj;
+try {
+ return Version.fromOrdinal(versionOrdinal);
+} catch (final UnsupportedSerializationVersionException e) {
Review comment:
**This right here** is a big fat problem. We are silently throwing away
information when the version ordinal represents an unknown version. One
approach is to let the exception escape (as a checked exception.) But that
entails fixing the 53 callers of this method. An alternative would be to
"tunnel" the checked exception through an unchecked one.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
>
> upgrade from version 1.12 doesn't seem to occur on the Locator
>
> testRollServersOnPartitionedRegion_dataserializable failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8213) C++ native client performance bottleneck in access to serialization registry
[ https://issues.apache.org/jira/browse/GEODE-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139212#comment-17139212 ] ASF GitHub Bot commented on GEODE-8213: --- albertogpz commented on pull request #611: URL: https://github.com/apache/geode-native/pull/611#issuecomment-645864860 This PR is closed as the solutions provided were not satisfactory. It will be revisited after #619 is merged as per the comments by @pivotal-jbarrett . This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > C++ native client performance bottleneck in access to serialization registry > > > Key: GEODE-8213 > URL: https://issues.apache.org/jira/browse/GEODE-8213 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.14.0 > > > It's been observed that when the number of threads used in a Geode client > using PdxSerialization is greater than 8, there is an important drop in > performance. > Analysing the client process behavior with perf, it has been observed a very > high CPU consumption by a spinlock > (apache::geode::util::concurrent::spinlock_mutex::lock) used when accessing > the serialization registry . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8213) C++ native client performance bottleneck in access to serialization registry
[ https://issues.apache.org/jira/browse/GEODE-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139206#comment-17139206 ] ASF GitHub Bot commented on GEODE-8213: --- albertogpz closed pull request #611: URL: https://github.com/apache/geode-native/pull/611 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > C++ native client performance bottleneck in access to serialization registry > > > Key: GEODE-8213 > URL: https://issues.apache.org/jira/browse/GEODE-8213 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.14.0 > > > It's been observed that when the number of threads used in a Geode client > using PdxSerialization is greater than 8, there is an important drop in > performance. > Analysing the client process behavior with perf, it has been observed a very > high CPU consumption by a spinlock > (apache::geode::util::concurrent::spinlock_mutex::lock) used when accessing > the serialization registry . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8213) C++ native client performance bottleneck in access to serialization registry
[ https://issues.apache.org/jira/browse/GEODE-8213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139207#comment-17139207 ] ASF GitHub Bot commented on GEODE-8213: --- albertogpz commented on pull request #611: URL: https://github.com/apache/geode-native/pull/611#issuecomment-645861561 > I think we should close this PR and revisit if after the fixes in #619 to be merged. After that I think It might just be safe to start by replacing the spinlock with just a plain old mutex to reduce the CPU load. It may not bench as good but solves the issue of CPU load under contention. I agree This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > C++ native client performance bottleneck in access to serialization registry > > > Key: GEODE-8213 > URL: https://issues.apache.org/jira/browse/GEODE-8213 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.14.0 > > > It's been observed that when the number of threads used in a Geode client > using PdxSerialization is greater than 8, there is an important drop in > performance. > Analysing the client process behavior with perf, it has been observed a very > high CPU consumption by a spinlock > (apache::geode::util::concurrent::spinlock_mutex::lock) used when accessing > the serialization registry . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8264) add unit test coverage of serialization code for RedisData classes
[ https://issues.apache.org/jira/browse/GEODE-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139142#comment-17139142 ] ASF GitHub Bot commented on GEODE-8264: --- dschneider-pivotal merged pull request #5260: URL: https://github.com/apache/geode/pull/5260 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > add unit test coverage of serialization code for RedisData classes > -- > > Key: GEODE-8264 > URL: https://issues.apache.org/jira/browse/GEODE-8264 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Major > > The classes that implement the RedisData interface should have unit tests > that verify that the serialization code is correct. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8264) add unit test coverage of serialization code for RedisData classes
[ https://issues.apache.org/jira/browse/GEODE-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8264. - Fix Version/s: 1.14.0 Resolution: Fixed > add unit test coverage of serialization code for RedisData classes > -- > > Key: GEODE-8264 > URL: https://issues.apache.org/jira/browse/GEODE-8264 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The classes that implement the RedisData interface should have unit tests > that verify that the serialization code is correct. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
