[jira] [Created] (GEODE-9409) NullPointerException while create region during server start
Mario Kevo created GEODE-9409:
-
Summary: NullPointerException while create region during server
start
Key: GEODE-9409
URL: https://issues.apache.org/jira/browse/GEODE-9409
Project: Geode
Issue Type: Bug
Components: gfsh, regions
Reporter: Mario Kevo
If the "create region" command is executed while the Geode server is starting
it will fail with NullPointerException on that server.
It happens for persistent regions as it tries to findDiskStore but in that
method, it first tries to get PdxRegistry from the cache and create a
persistent Region on that. But in that case, when the cache is creating, if the
command is executed fast it happened that creating cache is not finished and
pdxRegistry is null, so every method executed on that will throw
NulPointerException.
{code:java}
gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
--total-num-buckets=113 --disk-store=dataDiskStore
--enable-synchronous-disk=false
Member | Status | Message
--- | -- |
---
server1 | OK | Region "/test_region2" created on "server1"
server2 | OK | Region "/test_region2" created on "server2"
server3 | ERROR | java.lang.NullPointerException
at
org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
at
org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
Cluster configuration for group 'cluster' is updated.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9409) NullPointerException while create region during server start
[
https://issues.apache.org/jira/browse/GEODE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9409:
-
Assignee: Mario Kevo
> NullPointerException while create region during server start
>
>
> Key: GEODE-9409
> URL: https://issues.apache.org/jira/browse/GEODE-9409
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> If the "create region" command is executed while the Geode server is starting
> it will fail with NullPointerException on that server.
> It happens for persistent regions as it tries to findDiskStore but in that
> method, it first tries to get PdxRegistry from the cache and create a
> persistent Region on that. But in that case, when the cache is creating, if
> the command is executed fast it happened that creating cache is not finished
> and pdxRegistry is null, so every method executed on that will throw
> NulPointerException.
>
> {code:java}
> gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
> --total-num-buckets=113 --disk-store=dataDiskStore
> --enable-synchronous-disk=false
> Member | Status | Message
> --- | -- |
> ---
> server1 | OK | Region "/test_region2" created on "server1"
> server2 | OK | Region "/test_region2" created on "server2"
> server3 | ERROR | java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
> Cluster configuration for group 'cluster' is updated.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9405) Build fails on rhel-8 release
[
https://issues.apache.org/jira/browse/GEODE-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372584#comment-17372584
]
ASF GitHub Bot commented on GEODE-9405:
---
gaussianrecurrence commented on a change in pull request #826:
URL: https://github.com/apache/geode-native/pull/826#discussion_r662139036
##
File path: cppcache/integration-test/ThinClientSecurityHelper.hpp
##
@@ -59,13 +59,15 @@ const char* regionNamesAuth[] = {"DistRegionAck"};
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char* path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Be careful when assigning the output of std::getenv to an std::string.
If the env var is not defined it will return a nullptr, and passing a nullptr
to a std::string constructor result in a coredump. There is an utility function
Utils::getEnv which acts safely by returning an empty string when the variable
is not defined.
##
File path: cppcache/integration-test/testThinClientSecurityAuthentication.cpp
##
@@ -34,13 +34,15 @@ const char *regionNamesAuth[] = {"DistRegionAck",
"DistRegionNoAck"};
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path:
cppcache/integration-test/testThinClientSecurityAuthenticationSetAuthInitialize.cpp
##
@@ -35,13 +35,15 @@ const char *regionNamesAuth[] = {"DistRegionAck",
"DistRegionNoAck"};
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != NULL,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path: cppcache/integration-test/testThinClientSecurityAuthorization.cpp
##
@@ -54,13 +54,15 @@ const std::string locHostPort =
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path: cppcache/integration-test/testThinClientSecurityAuthorizationMU.cpp
##
@@ -65,13 +65,15 @@ std::shared_ptr
credentialGeneratorHandler;
const char *exFuncNameSendException = "executeFunction_SendException";
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path: cppcache/integration-test/testThinClientSecurityCQAuthorizationMU.cpp
##
@@ -138,13 +138,15 @@ class MyCqListener : public CqListener {
};
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path:
cppcache/integration-test/testThinClientSecurityDurableCQAuthorizationMU.cpp
##
@@ -139,13 +139,15 @@ class MyCqListener : public CqListener {
};
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
##
File path: cppcache/integration-test/testThinClientWriterException.cpp
##
@@ -52,13 +52,15 @@ const char *regionNamesAuth[] = {"DistRegionAck"};
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char *path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Same comment as above regarding code safety for std::getenv
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Build fails on rhel-8 release
> -
>
> Key: G
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372609#comment-17372609
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662145861
##
File path: cppcache/integration/test/PdxSerializerTest.cpp
##
@@ -115,18 +113,19 @@ std::shared_ptr setupRegion(Cache& cache) {
return region;
}
-void assertNonPdxType(const std::shared_ptr& expected,
- const std::shared_ptr& actual) {
- ASSERT_NE(nullptr, actual);
- auto pdxWrapper = std::dynamic_pointer_cast(actual);
- ASSERT_NE(nullptr, pdxWrapper);
- auto object = pdxWrapper->getObject();
- ASSERT_NE(nullptr, object);
+void expectNonPdxTypeEquals(const std::shared_ptr& expected,
+const std::shared_ptr& actual) {
+ EXPECT_TRUE(actual);
+
+ auto wrapper = std::dynamic_pointer_cast(actual);
+ EXPECT_TRUE(wrapper);
+
+ auto object = wrapper->getObject();
+ EXPECT_TRUE(object);
+
auto nonPdxType = std::static_pointer_cast(object);
- ASSERT_NE(nullptr, nonPdxType);
- EXPECT_EQ(2, nonPdxType->getLongValue());
+ EXPECT_TRUE(nonPdxType);
- EXPECT_NE(expected, nonPdxType);
EXPECT_EQ(*expected, *nonPdxType);
Review comment:
That's odd, I've used EXPECT_EQ lots of times with std::string. The way
EXPECT_EQ internally works is by calling operator== and if the comparison
fails, then both objects are serialized and shown the expected and actual in
the output. Problem is whenever there is no serialization possible for a pair
of objects you are comparing. In this case you would see an hexdump of the
objects that can't be serialized.
Serialization btw is done by calling the ostream& operator<<(ostream& os,
const ClassName& dt), so internally gtest uses SFINAE to check whether there is
or not an implementation for the specific object being serialized.
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372633#comment-17372633
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662174497
##
File path: cppcache/integration/test/PdxTypeRegistryTest.cpp
##
@@ -140,19 +141,60 @@ TEST(PdxTypeRegistryTest, cleanupOnClusterRestart) {
listener->waitConnected();
- key = "after-restart";
- region->put(key, createTestPdxInstance(cache, key));
+ region->put(key, pdx);
// If PdxTypeRegistry was cleaned up, then the PdxType should have been
// registered in the new cluster
std::shared_ptr result;
- auto query =
- qs->newQuery("SELECT * FROM /region WHERE entryName = '" + key + "'");
+ auto query = qs->newQuery("SELECT * FROM /region WHERE int_value = -1");
EXPECT_NO_THROW(result = query->execute());
EXPECT_TRUE(result);
- EXPECT_GT(result->size(), 0);
+ EXPECT_EQ(result->size(), 1);
Review comment:
You've got a pretty good point. I've got so many changes in my head that
by mistake I changed this test behaviour. This was working fine as it was. I'll
revert this test changes. Also, what do you think about adding some comments to
clarify how these tests works? I mean cleanupOnClusterRestart and
cleanupOnClusterRestartAndFetchFields
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372636#comment-17372636
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662178266
##
File path: cppcache/integration/test/PdxTypeRegistryTest.cpp
##
@@ -140,19 +141,60 @@ TEST(PdxTypeRegistryTest, cleanupOnClusterRestart) {
listener->waitConnected();
- key = "after-restart";
- region->put(key, createTestPdxInstance(cache, key));
+ region->put(key, pdx);
// If PdxTypeRegistry was cleaned up, then the PdxType should have been
// registered in the new cluster
std::shared_ptr result;
- auto query =
- qs->newQuery("SELECT * FROM /region WHERE entryName = '" + key + "'");
+ auto query = qs->newQuery("SELECT * FROM /region WHERE int_value = -1");
EXPECT_NO_THROW(result = query->execute());
EXPECT_TRUE(result);
- EXPECT_GT(result->size(), 0);
+ EXPECT_EQ(result->size(), 1);
}
+TEST(PdxTypeRegistryTest, cleanupOnClusterRestartAndFetchFields) {
+ Cluster cluster{LocatorCount{1}, ServerCount{2}};
+ cluster.start();
+
+ auto& gfsh = cluster.getGfsh();
+ gfsh.create().region().withName("region").withType("PARTITION").execute();
+
+ auto listener = std::make_shared();
+
+ auto cache = createTestCache();
+ createTestPool(cluster, cache);
+ auto qs = cache.getQueryService("pool");
+ auto region = createTestRegion(cache, listener);
+
+ std::string key = "before-shutdown";
+ region->put(key, createTestPdxInstance(cache, key));
+ auto object = region->get(key);
+ EXPECT_TRUE(object);
+
+ auto pdx = std::dynamic_pointer_cast(object);
+ EXPECT_TRUE(pdx);
+
+ // Shutdown and wait for some time
+ gfsh.shutdown().execute();
+ listener->waitDisconnected();
+ std::this_thread::sleep_for(std::chrono::seconds{15});
+
+ for (auto& server : cluster.getServers()) {
+server.start();
+ }
+
+ listener->waitConnected();
+ auto fields = pdx->getFieldNames();
+ EXPECT_TRUE(fields);
+
+ std::set fields_set;
+ for (auto field : fields->value()) {
+fields_set.insert(field->toString());
+ }
+
+ EXPECT_EQ(fields_set.count("entryName"), 1);
Review comment:
This is not the purpose of the test, as it was originally designed
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372645#comment-17372645
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662180518
##
File path: cppcache/src/PdxInstanceImpl.hpp
##
@@ -211,35 +210,36 @@ class PdxInstanceImpl : public WritablePdxInstance {
void operator=(const PdxInstanceImpl& other) = delete;
- std::shared_ptr getPdxType() const;
+ std::shared_ptr getPdxType(Pool* pool) const;
- void updatePdxStream(uint8_t* newPdxStream, int len);
+ int32_t getTypeId() const;
+
+ void updatePdxStream(std::vector stream);
+
+ protected:
+ const std::vector& getPdxStream() const;
private:
- std::vector m_buffer;
- int m_typeId;
+ mutable std::vector m_buffer;
+ mutable int32_t m_typeId;
Review comment:
This is by convention member variables that are lazily initializated are
supposed to be mutable. The reason is because once initialized they are
supposed to be immutable, but sadly there is no support from the language for
lazy initialization, so that's the way it's usually done.
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372642#comment-17372642
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662171627
##
File path: cppcache/src/PdxLocalWriter.cpp
##
@@ -330,13 +330,13 @@ PdxWriter& PdxLocalWriter::markIdentityField(const
std::string&) {
return *this;
}
-uint8_t* PdxLocalWriter::getPdxStream(int& pdxLen) {
- uint8_t* stPos =
+std::vector PdxLocalWriter::getPdxStream() {
+ uint8_t* buffer =
const_cast(m_dataOutput->getBuffer()) + m_startPositionOffset;
- int len = PdxHelper::readInt32 /*readByte*/ (stPos);
- pdxLen = len;
- // ignore len and typeid
- return m_dataOutput->getBufferCopyFrom(stPos + 8, len);
+ int32_t len = PdxHelper::readInt32(buffer);
+ buffer += 8;
+
+ return {buffer, buffer + len};
Review comment:
You've got a pretty good point. I think I'll use the explicit
construction, rather than the implicit, so it's more clear what's happening
there.
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372655#comment-17372655
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662177445
##
File path: cppcache/integration/test/PdxTypeRegistryTest.cpp
##
@@ -140,19 +141,60 @@ TEST(PdxTypeRegistryTest, cleanupOnClusterRestart) {
listener->waitConnected();
- key = "after-restart";
- region->put(key, createTestPdxInstance(cache, key));
+ region->put(key, pdx);
// If PdxTypeRegistry was cleaned up, then the PdxType should have been
// registered in the new cluster
std::shared_ptr result;
- auto query =
- qs->newQuery("SELECT * FROM /region WHERE entryName = '" + key + "'");
+ auto query = qs->newQuery("SELECT * FROM /region WHERE int_value = -1");
EXPECT_NO_THROW(result = query->execute());
EXPECT_TRUE(result);
- EXPECT_GT(result->size(), 0);
+ EXPECT_EQ(result->size(), 1);
}
+TEST(PdxTypeRegistryTest, cleanupOnClusterRestartAndFetchFields) {
+ Cluster cluster{LocatorCount{1}, ServerCount{2}};
+ cluster.start();
+
+ auto& gfsh = cluster.getGfsh();
+ gfsh.create().region().withName("region").withType("PARTITION").execute();
+
+ auto listener = std::make_shared();
+
+ auto cache = createTestCache();
+ createTestPool(cluster, cache);
+ auto qs = cache.getQueryService("pool");
+ auto region = createTestRegion(cache, listener);
+
+ std::string key = "before-shutdown";
+ region->put(key, createTestPdxInstance(cache, key));
+ auto object = region->get(key);
+ EXPECT_TRUE(object);
+
+ auto pdx = std::dynamic_pointer_cast(object);
+ EXPECT_TRUE(pdx);
+
+ // Shutdown and wait for some time
+ gfsh.shutdown().execute();
+ listener->waitDisconnected();
+ std::this_thread::sleep_for(std::chrono::seconds{15});
+
+ for (auto& server : cluster.getServers()) {
+server.start();
+ }
+
+ listener->waitConnected();
+ auto fields = pdx->getFieldNames();
Review comment:
Indeed, you've got a point, that at first glance it'd be hard to
understand why this test exists. I think it would be best to add a comment with
its description.
Thing is what's being tested here is the following:
- You create a PdxInstance called pdx
- Cluster is restarted and the PdxTypeRegister is cleaned up.
- You try to traverse the PdxInstance and you expect there are no coredumps.
In this case getFieldNames is used for example.
Thing is, prior to this change, getFieldNames as many other methods tried to
fetch the PdxType by querying the register with its ID, and given it was just
cleaned up, it was returning a nullptr, hence coredump.
Being all of this said. You think it would be best to check all of the
methods that reads the PdxInstance content?
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9268) Fix coredump whenever getFieldNames is called after a cluster restart
[
https://issues.apache.org/jira/browse/GEODE-9268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372657#comment-17372657
]
ASF GitHub Bot commented on GEODE-9268:
---
gaussianrecurrence commented on a change in pull request #806:
URL: https://github.com/apache/geode-native/pull/806#discussion_r662179040
##
File path: cppcache/src/PdxHelper.cpp
##
@@ -175,61 +163,59 @@ std::shared_ptr
PdxHelper::deserializePdx(DataInput& dataInput,
auto pType = pdxTypeRegistry->getPdxType(typeId);
if (pType) {
// this may happen with PdxInstanceFactory
-pdxLocalType = pdxTypeRegistry->getLocalPdxType(pType->getPdxClassName());
+localType = pdxTypeRegistry->getLocalPdxType(pType->getPdxClassName());
}
- if (pType && pdxLocalType) {
+ if (pType && localType) {
// type found
auto&& pdxClassname = pType->getPdxClassName();
LOGDEBUG("deserializePdx ClassName = " + pdxClassname +
", isLocal = " + std::to_string(pType->isLocal()));
-pdxObjectptr = serializationRegistry->getPdxSerializableType(pdxClassname);
+object = serializationRegistry->getPdxSerializableType(pdxClassname);
if (pType->isLocal()) // local type no need to read Unread data
{
auto plr = PdxLocalReader(dataInput, pType, length, pdxTypeRegistry);
- pdxObjectptr->fromData(plr);
+ object->fromData(plr);
plr.moveStream();
} else {
auto prr = PdxRemoteReader(dataInput, pType, length, pdxTypeRegistry);
- pdxObjectptr->fromData(prr);
+ object->fromData(prr);
auto mergedVersion = pdxTypeRegistry->getMergedType(pType->getTypeId());
- auto preserveData = prr.getPreservedData(mergedVersion, pdxObjectptr);
+ auto preserveData = prr.getPreservedData(mergedVersion, object);
if (preserveData != nullptr) {
pdxTypeRegistry->setPreserveData(
-pdxObjectptr, preserveData,
+object, preserveData,
cacheImpl
->getExpiryTaskManager()); // it will set data in weakhashmap
}
prr.moveStream();
- if (auto pdxWrapper =
- std::dynamic_pointer_cast(pdxObjectptr)) {
-if (!pdxWrapper->getObject()) {
+ if (auto wrapper = std::dynamic_pointer_cast(object)) {
+if (!wrapper->getObject()) {
// No serializer was registered to deserialize this type.
// Fall back to PdxInstance
return nullptr;
}
}
}
} else {
-// type not found; need to get from server
-if (!pType) {
+if (pType == nullptr) {
Review comment:
Indeed, sorry I try to leave aside my coding conventions hehe, but
sometimes I don't notice. Will change it
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix coredump whenever getFieldNames is called after a cluster restart
> -
>
> Key: GEODE-9268
> URL: https://issues.apache.org/jira/browse/GEODE-9268
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *WHEN* A PdxInstance is fetched from a region
> *AND* The whole cluster is restarted, triggering PdxTypeRegistry cleanup.
> *AND* getFieldNames is called on the PdxInstance created just before
> *THEN* a coredump happens.
> —
> *Additional information:*
> Callstack:
> {noformat}
> [ERROR 2021/05/05 12:57:12.781834 CEST main (139683590957120)] Segmentation
> fault happened
> 0# handler(int) at nc-pdx/main.cpp:225
> 1# 0x7F0A9F5F13C0 in /lib/x86_64-linux-gnu/libpthread.so.0
> 2# apache::geode::client::PdxType::getPdxFieldTypes() const at
> cppcache/src/PdxType.hpp:181
> 3# apache::geode::client::PdxInstanceImpl::getFieldNames() at
> cppcache/src/PdxInstanceImpl.cpp:1383
> 4# main at nc-pdx/main.cpp:374
> 5# __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
> 6# _start in build/pdx{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8719:
---
Fix Version/s: (was: 1.14.0)
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Jens Deppe
>Priority: Minor
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8719:
---
Affects Version/s: 1.15.0
1.14.0
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Sarah Abbey
>Assignee: Jens Deppe
>Priority: Minor
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9405) Build fails on rhel-8 release
[
https://issues.apache.org/jira/browse/GEODE-9405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17372941#comment-17372941
]
ASF GitHub Bot commented on GEODE-9405:
---
pivotal-jbarrett commented on a change in pull request #826:
URL: https://github.com/apache/geode-native/pull/826#discussion_r662460657
##
File path: cppcache/integration-test/ThinClientSecurityHelper.hpp
##
@@ -59,13 +59,15 @@ const char* regionNamesAuth[] = {"DistRegionAck"};
std::shared_ptr credentialGeneratorHandler;
std::string getXmlPath() {
- char xmlPath[1000] = {'\0'};
- const char* path = std::getenv("TESTSRC");
- ASSERT(path != nullptr,
+ std::string path = std::string(std::getenv("TESTSRC"));
Review comment:
Oh yes, good catch!!
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Build fails on rhel-8 release
> -
>
> Key: GEODE-9405
> URL: https://issues.apache.org/jira/browse/GEODE-9405
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Labels: pull-request-available
>
> Looks like a recent gcc compiler change on rhel-8 is causing build failures
> in the CI.
> Looks to be related to unsafe use of strncpy in a few of our legacy C++ tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9337) CI: session.NativeRedisSessionAcceptanceTest failed with Suspicious strings
[ https://issues.apache.org/jira/browse/GEODE-9337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9337. Resolution: Duplicate > CI: session.NativeRedisSessionAcceptanceTest failed with Suspicious strings > --- > > Key: GEODE-9337 > URL: https://issues.apache.org/jira/browse/GEODE-9337 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Assignee: Ray Ingles >Priority: Major > > In acceptance test: > > Task :geode-apis-compatible-with-redis:acceptanceTest > session.NativeRedisSessionAcceptanceTest > classMethod FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-local.log' at line 1445 > [error 2021/06/01 17:35:16.963 UTC tid=98] Failed to > return response on inboundChannel > io.netty.channel.StacklessClosedChannelException > at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, > ChannelPromise)(Unknown Source) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:185) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:69) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:140) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182) > at > org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164) > at > org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) > at > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.uti
[jira] [Resolved] (GEODE-9310) Geode redis should send error message when encounter DistributedSystemDisconnectedException, ForcedDisconnectException or FunctionInvocationTargetException
[
https://issues.apache.org/jira/browse/GEODE-9310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-9310.
Resolution: Invalid
With the removal of function execution in GEODE-9168, this issue is no longer
valid, as the code described has been removed.
> Geode redis should send error message when encounter
> DistributedSystemDisconnectedException, ForcedDisconnectException or
> FunctionInvocationTargetException
> ---
>
> Key: GEODE-9310
> URL: https://issues.apache.org/jira/browse/GEODE-9310
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Eric Shu
>Priority: Major
>
> Currently when redis function execution encounter these exception, it will
> just close the client connection.
> {code:java}
> else if (cause instanceof FunctionInvocationTargetException
> || cause instanceof DistributedSystemDisconnectedException
> || cause instanceof ForcedDisconnectException) {
> // This indicates a member departed or got disconnected
> logger.warn(
> "Closing client connection because one of the servers doing this
> operation departed.");
> channelInactive(ctx);
> response = null;
> }
> {code}
> This is incorrect, as this could lead to client performing retries of the
> same redis command.
> The correct way is to send an error response that command may or may not have
> been executed on servers, user need to verify and retry if necessary.
> Here is a test result showing that current behavior of client retrying:
> The node executing the ZREM command:
> (vm1 gets the connection from JedisCluster client)
> [vm1] [warn 2021/05/25 15:31:26.732 PDT server-1
> tid=0xfb] Executing Redis command: ZREM key member1-212 member1-211
> member1-214 member1-213 member1-210 member1-209 member1-208 member1-205
> member1-204
> (primary is on vm3 and it is execute the function)
> [vm3] [warn 2021/05/25 15:31:26.692 PDT server-3 Processor3> tid=0xf3] bucket region is
> BucketRegion[path='/__PR/_B__REDIS__DATA_123;serial=399;primary=true] key key
> [vm3] java.lang.Exception
> [vm3] at
> org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:533)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586)
> [vm3] at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1213)
> [vm3] at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:3024)
> [vm3] at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2236)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5044)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1645)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1632)
> [vm3] at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> [vm3] at
> org.apache.geode.redis.internal.data.AbstractRedisData.storeChanges(AbstractRedisData.java:218)
> [vm3] at
> org.apache.geode.redis.internal.data.RedisSortedSet.zrem(RedisSortedSet.java:239)
> [vm3] at
> org.apache.geode.redis.internal.data.RedisSortedSetCommandsFunctionExecutor.lambda$zrem$2(RedisSortedSetCommandsFunctionExecutor.java:50)
> [vm3] at
> org.apache.geode.redis.internal.executor.SynchronizedStripedExecutor.execute(SynchronizedStripedExecutor.java:47)
> [vm3] at
> org.apache.geode.redis.internal.data.RedisDataCommandsFunctionExecutor.stripedExecute(RedisDataCommandsFunctionExecutor.java:43)
> [vm3] at
> org.apache.geode.redis.internal.data.RedisSortedSetCommandsFunctionExecutor.zrem(RedisSortedSetCommandsFunctionExecutor.java:49)
> [vm3] at
> org.apache.geode.redis.internal.executor.CommandFunction.compute(CommandFunction.java:289)
> [vm3] at
> org.apache.geode.redis.internal.executor.SingleResultRedisFunction.lambda$execute$0(SingleResultRedisFunction.java:47)
> [vm3] at
> org.apache.geode.internal.cache.PartitionedRegion.computeWithPrimaryLocked(PartitionedRegion.java:629)
> [vm3] at
> org.apache.geode.redis.internal.executor.SingleResultRedisFunction.execute(SingleResultRedisFunction.java:51)
> [vm3] at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.executeOnDataStore(PartitionedRegionDa
[jira] [Created] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
Dave Barnes created GEODE-9410: -- Summary: User Guide: gfsh import cluster-configuration inconsistencies Key: GEODE-9410 URL: https://issues.apache.org/jira/browse/GEODE-9410 Project: Geode Issue Type: Bug Components: docs Affects Versions: 1.13.3 Reporter: Dave Barnes Two write-ups on the gfsh import cluster-configuration command seem to differ with regard to whether the operation is allowed on running cache servers. The operation is allowed, but with restrictions. The correct details are provided in the gfsh import command description: [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] The corresponding section under Exporting and Importing Cluster Configurations is less clear, and could be improved: https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-9410: -- Assignee: Dave Barnes > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-9410: --- Priority: Minor (was: Major) > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9311) It is possible that JedisCluster client may still retry if the Geode Redis server it is connected to shuts down
[ https://issues.apache.org/jira/browse/GEODE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9311. Fix Version/s: 1.15.0 Resolution: Fixed With the changes in GEODE-9303, the client connection is no longer closed upon encountering an error during command execution (except for IOExceptions) so this issue should not occur. > It is possible that JedisCluster client may still retry if the Geode Redis > server it is connected to shuts down > --- > > Key: GEODE-9311 > URL: https://issues.apache.org/jira/browse/GEODE-9311 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Fix For: 1.15.0 > > > Even after the issue (GEODE-9310) is addressed, the retry issue may still > occur if the JedisCluster client is connected to the node is being shut down. > Here is a test run result: > vm2 gets the command: > [vm2] [warn 2021/05/25 16:01:41.479 PDT server-2 > tid=0x64] Executing Redis command: ZREM key member1-212 member1-211 > member1-214 member1-213 member1-210 member1-209 member1-208 member1-205 > member1-204 > *** command is executed on the primary *** > [vm2] [warn 2021/05/25 16:01:41.503 PDT server-2 Processor2> tid=0x51] bucket region is > BucketRegion[path='/__PR/_B__REDIS__DATA_123;serial=200;primary=true] key key > [vm2] java.lang.Exception > [vm2] at > org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:533) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1213) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:3024) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2236) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > And distributed to replica (vm1): > vm1] [warn 2021/05/25 16:01:41.518 PDT server-1 192.168.0.14(server-2:83136):41002 shared ordered sender uid=7 local > port=58643 remote port=53459> tid=0x59] membersRemoveAll invoked > [vm1] java.lang.Exception > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.membersRemoveAll(RedisSortedSet.java:175) > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.applyDelta(RedisSortedSet.java:89) > [vm1] at > org.apache.geode.redis.internal.data.AbstractRedisData.fromDelta(AbstractRedisData.java:193) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1841) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.setNewValueInRegion(EntryEventImpl.java:1696) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.putExistingEntry(EntryEventImpl.java:1643) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.updateEntry(RegionMapPut.java:485) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.createOrUpdateEntry(RegionMapPut.java:256) > vm2 is bounced: > [vm2] [info 2021/05/25 16:01:41.526 PDT server-2 Connection(1)-192.168.0.14> tid=0x14] Got result: 83136 > [vm2] from org.apache.geode.test.dunit.VM$$Lambda$370/1141741369.call with 0 > args on object: > org.apache.geode.test.dunit.VM$$Lambda$370/1141741369@68ecd55a (took 0 ms) > [info 2021/05/25 16:01:41.527 PDT tid=0x36] Bouncing 2 old > pid is 83136 and version is 10240.0.0 > The JedisCluster client did not get response back (possibly detects > connection is gone), and it does retry again, as the test failed with > following: > java.util.concurrent.ExecutionException: > redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more > cluster attempts left. > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.Fram
[jira] [Updated] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9410: -- Labels: pull-request-available (was: ) > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8192) Redis MSET command needs to be atomic
[ https://issues.apache.org/jira/browse/GEODE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-8192: -- Assignee: Donal Evans > Redis MSET command needs to be atomic > - > > Key: GEODE-8192 > URL: https://issues.apache.org/jira/browse/GEODE-8192 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Donal Evans >Priority: Major > > All of the supported and unsupported redis string commands (for the 1.14 > release) that need to be atomic now are except for MSET. > Note that MGET does not need to be atomic. > To make MSET atomic it could do something like RENAME does to lock multiple > keys in a manner that prevent a distributed deadlock. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8192) Redis MSET command needs to be atomic
[ https://issues.apache.org/jira/browse/GEODE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-8192: -- Assignee: (was: Donal Evans) > Redis MSET command needs to be atomic > - > > Key: GEODE-8192 > URL: https://issues.apache.org/jira/browse/GEODE-8192 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > > All of the supported and unsupported redis string commands (for the 1.14 > release) that need to be atomic now are except for MSET. > Note that MGET does not need to be atomic. > To make MSET atomic it could do something like RENAME does to lock multiple > keys in a manner that prevent a distributed deadlock. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373027#comment-17373027 ] ASF subversion and git services commented on GEODE-9410: Commit 9c55efe4619b207c83646193b37f5cbe9f1c5877 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c55efe ] GEODE-9410: User Guide - resolve inconsistencies in gfsh import cluster-configuration command description (#6669) > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender
[ https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373052#comment-17373052 ] ASF subversion and git services commented on GEODE-8971: Commit d0dadde6dd26fc766c15ea7e935d99884278f4cd in geode's branch refs/heads/GEODE-9375-Implement-ZRANGE-Radish-command from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d0dadde ] Revert "GEODE-8971: Add grace period when stopping gateway sender with group-… (#6052)" (#6634) This reverts commit 841fa06c7b34916c09df920b7029974a78255cd0. The reason is that this commit creates problems with ongoing put operations during the grace period (very long response times) and also, if operations rate is high, it could prevent that the gateway sender is stopped. Put operations can be very slow during the grace period because they need to traverse the gateway sender queue to find events with the same transactionId. If the queue size is big and events are evicted to disk, the time to process a request can be unacceptably long. At the same time, this can provoke that the gateway sender is never stopped because it is blocked trying to get a write lock and the lock is held by ongoing operations for a long time. > Batches with incomplete transactions when stopping the gateway sender > - > > Key: GEODE-8971 > URL: https://issues.apache.org/jira/browse/GEODE-8971 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When the gateway sender is stopped there is a high probability that batches > with incomplete transactions are sent even if group-transaction-events is > enabled. > The reason is that once the stop command reaches the gateway sender, it > immediately stops queueing events, and this could happen in the middle of > receiving events for the same transaction. If this is the case, some events > for the transaction may have reached the queue right before the stop command > was received and the rest of events for that transaction would not make it to > the queue (they would be dropped) because they arrived right after the stop > command was received at the gateway sender. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373051#comment-17373051 ] ASF subversion and git services commented on GEODE-9410: Commit 9c55efe4619b207c83646193b37f5cbe9f1c5877 in geode's branch refs/heads/GEODE-9375-Implement-ZRANGE-Radish-command from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c55efe ] GEODE-9410: User Guide - resolve inconsistencies in gfsh import cluster-configuration command description (#6669) > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9403) Dockerfile uses an unreliable key server
[ https://issues.apache.org/jira/browse/GEODE-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373050#comment-17373050 ] ASF subversion and git services commented on GEODE-9403: Commit b037f2f498c74ae88c408e9977235f33d6d4e77d in geode's branch refs/heads/GEODE-9375-Implement-ZRANGE-Radish-command from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b037f2f ] GEODE-9403: use a better keyserver in Dockerfile (#6648) * sks-keyservers is going away, so use a better one * also patch this change into support branches upon their next release > Dockerfile uses an unreliable key server > > > Key: GEODE-9403 > URL: https://issues.apache.org/jira/browse/GEODE-9403 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > This line in docker/Dockerfile stopped working for me: > `gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$GEODE_GPG";` > I found that changing it to this works: > `gpg --keyserver [keyserver.ubuntu.com|http://keyserver.ubuntu.com/] > --recv-keys "$GEODE_GPG";` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9006) MemoryStatsNativeRedisAcceptanceTest CI failure
[
https://issues.apache.org/jira/browse/GEODE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373058#comment-17373058
]
ASF subversion and git services commented on GEODE-9006:
Commit 690aad735d75d6dfb921a48f8de068272c17c121 in geode's branch
refs/heads/support/1.14 from John Hutchison
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=690aad7 ]
GEODE-9006: fix flaky native Redis memory usage test (#6456)
- rename test to be more specific
- increase size of data added in test
- remove unused fields and methods
(cherry picked from commit 6d5398747871a5c27c1eb936b299ba311a1444c1)
> MemoryStatsNativeRedisAcceptanceTest CI failure
> ---
>
> Key: GEODE-9006
> URL: https://issues.apache.org/jira/browse/GEODE-9006
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> CI failure:
> {{org.apache.geode.redis.internal.executor.server.MemoryStatsNativeRedisAcceptanceTest
> > usedMemory_shouldReflectActualMemoryUsage FAILED
> java.lang.AssertionError:
> Expecting:
> 854912L
> to be greater than:
> 855176L}}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/51]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9006) MemoryStatsNativeRedisAcceptanceTest CI failure
[
https://issues.apache.org/jira/browse/GEODE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-9006.
Fix Version/s: 1.14.0
Resolution: Fixed
> MemoryStatsNativeRedisAcceptanceTest CI failure
> ---
>
> Key: GEODE-9006
> URL: https://issues.apache.org/jira/browse/GEODE-9006
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> CI failure:
> {{org.apache.geode.redis.internal.executor.server.MemoryStatsNativeRedisAcceptanceTest
> > usedMemory_shouldReflectActualMemoryUsage FAILED
> java.lang.AssertionError:
> Expecting:
> 854912L
> to be greater than:
> 855176L}}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/51]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9168) Remove Function Execution
[ https://issues.apache.org/jira/browse/GEODE-9168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9168. Resolution: Fixed > Remove Function Execution > - > > Key: GEODE-9168 > URL: https://issues.apache.org/jira/browse/GEODE-9168 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Because operations go directly to the primary with cluster mode enabled, we > don’t need to use functions to route to the primary. > If we are already executing on the primary, we can eliminate function > execution code. > +Acceptance Criteria+ > When operating in compatibility with Redis mode, function execution is > eliminated when executing on the primary node. > Geode benchmarks perform better after this change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9362) Implement ZADD option INCR
[ https://issues.apache.org/jira/browse/GEODE-9362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9362. Fix Version/s: 1.15.0 Resolution: Fixed > Implement ZADD option INCR > -- > > Key: GEODE-9362 > URL: https://issues.apache.org/jira/browse/GEODE-9362 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > INCR: When this option is specified ZADD acts like ZINCRBY. Only one > score-element pair can be specified in this mode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9166) Implement the MOVED Redirection
[ https://issues.apache.org/jira/browse/GEODE-9166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9166. Resolution: Fixed > Implement the MOVED Redirection > --- > > Key: GEODE-9166 > URL: https://issues.apache.org/jira/browse/GEODE-9166 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [MOVED|https://redis.io/topics/cluster-spec#moved-redirection] > Redirection as compatible with Redis and the > [RFC|https://cwiki.apache.org/confluence/display/GEODE/Geode+Compatibility+with+Redis+data+sharding+and+cluster+changes]. > > +Acceptance Criteria+ > New DUnit tests are developed to assert that the behavior is correct. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9303) Implement the DUMP and Restore Commands
[ https://issues.apache.org/jira/browse/GEODE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9303. Fix Version/s: 1.15.0 Resolution: Fixed > Implement the DUMP and Restore Commands > --- > > Key: GEODE-9303 > URL: https://issues.apache.org/jira/browse/GEODE-9303 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [DUMP|https://redis.io/commands/dump] and > [RESTORE|https://redis.io/commands/restore] commands as compatible with Redis. > > +Acceptance Criteria+ > The DUMP and RESTORE commands have been implemented as specified, with > adequate unit and integration tests. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
Donal Evans created GEODE-9411:
--
Summary: ExecutionHandlerContext.getExceptionResponse() should not
close the client connection on IOException
Key: GEODE-9411
URL: https://issues.apache.org/jira/browse/GEODE-9411
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
response of some kind to the client, except for if we hit an {{IOException}}
during command execution, in which case we close the client connection and
don't send any reply. This behaviour is leftover from the now-removed function
execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-9411:
--
Assignee: Donal Evans
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9411:
--
Labels: pull-request-available (was: )
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
