[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232747#comment-17232747
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo opened a new pull request #693:
URL: https://github.com/apache/geode-native/pull/693
HandleReplay is already commented in other functions as replay is
unsupported, this change will not translate the real exception to
UnknownException.
User will got correct exception and will know how to handle 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExec
[jira] [Updated] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8442:
--
Labels: pull-request-available (was: )
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.apache.geode.internal.cache.ForceReattemptException:
> PartitionResponse got remote CacheClosedException
> at
> org.apache.geode.inte
[jira] [Commented] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232794#comment-17232794
]
ASF GitHub Bot commented on GEODE-8614:
---
gaussianrecurrence commented on a change in pull request #688:
URL: https://github.com/apache/geode-native/pull/688#discussion_r524311436
##
File path: cppcache/integration/test/ExceptionTranslationTest.cpp
##
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include "framework/Cluster.h"
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableKey;
+using apache::geode::client::CacheableString;
+using apache::geode::client::LowMemoryException;
+using apache::geode::client::Pool;
+using apache::geode::client::QueryExecutionLowMemoryException;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+using std::chrono::minutes;
+
+namespace {
+Cache createCache() {
+ using apache::geode::client::CacheFactory;
+
+ auto cache = CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+
+ return cache;
+}
+
+std::shared_ptr createPool(Cluster& cluster, Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(Cache& cache,
+const std::shared_ptr& pool) {
+ auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName(pool->getName())
+.create("region");
+
+ return region;
+}
+
+void createEntries(const std::shared_ptr& region, std::size_t count,
+ std::size_t size) {
+ std::mt19937 generator{std::random_device{}()};
+ std::string base{"ABCDEFGHIJKLMNOPQRSTUVWXYZ"};
+
+ while (base.length() < size) {
+base += base;
+ }
+ base = base.substr(0, size);
+
+ for (std::size_t i = 0U; i < count;) {
+std::string value_str{base};
+std::shuffle(value_str.begin(), value_str.end(), generator);
+
+auto key = CacheableKey::create(std::to_string(i++));
+auto value = CacheableString::create(value_str);
+region->put(key, value);
+ }
+}
+} // namespace
+
+TEST(ExceptionTranslationTest, testLowMemoryException) {
+ const auto ENTRY_SIZE = 1024U;
+ const auto ENTRIES = 1U << 20U;
+
+ Cluster cluster{LocatorCount{1}, ServerCount{1},
+ CacheXMLFiles{std::vector{
Review comment:
I changed the cluster initialization so it improves readability.
Hopefully that was what you went for with your comment :)
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
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are runnin
[jira] [Resolved] (GEODE-8684) Setting a session's maxInactiveInterval does not work when the commit valve is disabled
[
https://issues.apache.org/jira/browse/GEODE-8684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey resolved GEODE-8684.
Fix Version/s: 1.14.0
Resolution: Fixed
> Setting a session's maxInactiveInterval does not work when the commit valve
> is disabled
> ---
>
> Key: GEODE-8684
> URL: https://issues.apache.org/jira/browse/GEODE-8684
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> I was using the {{CommandServlet}}, in an external test, and noticed that
> when the commit valve is disabled, attempting to set the session's
> maxInactiveInterval does not cause the session's maxInactiveInterval to be
> changed and it remains at the default.
> My setup consisted of 2 Geode servers and a single Tomcat instance (9.0.39).
> I was checking the sessions with the following gfsh query:
> {code:java}
> query --query="select e.key,e.value.maxInactiveInterval from
> /gemfire_modules_sessions.entries as e
> {code}
> My {{context.xml}} includes the following:
> {code:xml}
>className="org.apache.geode.modules.session.catalina.Tomcat8DeltaSessionManager"
> enableLocalCache="false"
> enableCommitValve="false"
> regionAttributesId="PARTITION_REDUNDANT"
> />
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232844#comment-17232844
]
ASF GitHub Bot commented on GEODE-8697:
---
bschuchardt merged pull request #5739:
URL: https://github.com/apache/geode/pull/5739
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
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.partitio
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232846#comment-17232846
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(Reply
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232845#comment-17232845
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(Reply
[jira] [Resolved] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8697.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.partitioned.FetchKeysMessage$FetchKeysResponse.waitForKeys(FetchKeysMessage.java:584)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getBucketKeys(PartitionedRegion.java:4463)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataView.getBucketKeys(PartitionedRegionDataView.java:118)
> at
> org.apache.geode.internal.cache.PartitionedRegion$KeysSet$KeysSetIterat
[jira] [Resolved] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8670.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8670:
-
Assignee: Bruce J Schuchardt
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
John Hutchison created GEODE-8715: - Summary: Redis INFO command 'Keyspace' section should not be present if no keys in database Key: GEODE-8715 URL: https://issues.apache.org/jira/browse/GEODE-8715 Project: Geode Issue Type: Improvement Components: redis Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232865#comment-17232865 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison commented on pull request #5748: URL: https://github.com/apache/geode/pull/5748#issuecomment-728161074 > Seems good! Just looks like it needs a Jira ticket. [GEODE-8706](https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8706) looks like it's for a different issue. so it does- weird- not sure how that happened \_?_/ . thanks- fixed. 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8715: -- Labels: pull-request-available (was: ) > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232876#comment-17232876 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison opened a new pull request #5753: URL: https://github.com/apache/geode/pull/5753 …nt if no keys in database 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232879#comment-17232879
]
Geode Integration commented on GEODE-7710:
--
Seen in [DistributedTestOpenJDK8
#624|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/624]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0487/test-results/distributedTest/1605328331/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0487/test-artifacts/1605328331/distributedtestfiles-OpenJDK8-1.14.0-build.0487.tgz].
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232883#comment-17232883 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison commented on pull request #5748: URL: https://github.com/apache/geode/pull/5748#issuecomment-728173547 > > Seems good! Just looks like it needs a Jira ticket. [GEODE-8706](https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8706) looks like it's for a different issue. > > so it does- weird- not sure how that happened _?_/ . thanks- fixed. re-opened pr in https://github.com/apache/geode/pull/5753 with renamed branch and pr. closing this pr. 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232885#comment-17232885 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison commented on pull request #5748: URL: https://github.com/apache/geode/pull/5748#issuecomment-728174115 mistakenly assigned unrelated ticket. Pr closed and reopened in new pr https://github.com/apache/geode/pull/5753 with matching branch name 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232884#comment-17232884 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison closed pull request #5748: URL: https://github.com/apache/geode/pull/5748 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232888#comment-17232888 ] ASF GitHub Bot commented on GEODE-8715: --- jhutchison commented on pull request #5753: URL: https://github.com/apache/geode/pull/5753#issuecomment-728174609 previously submitted under https://github.com/apache/geode/pull/5748 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8716) TombstoneDUnitTests fail with a BindException creating a cache server on the default port
Bruce J Schuchardt created GEODE-8716:
-
Summary: TombstoneDUnitTests fail with a BindException creating a
cache server on the default port
Key: GEODE-8716
URL: https://issues.apache.org/jira/browse/GEODE-8716
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Bruce J Schuchardt
The test should be changed to do a wildcard bind (setPort(0)).
{noformat}
org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
testGetOldestTombstoneNonReplicate FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$46/1195148372.run
in VM 1 running on Host e45ce8a4541a with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
at
org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneNonReplicate(TombstoneDUnitTest.java:223)
Caused by:
java.net.BindException: Failed to create server socket on
172.17.0.20[40404]
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
at
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
at
org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
at
org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:384)
at
org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneNonReplicate$bb17a952$1(TombstoneDUnitTest.java:225)
Caused by:
java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:390)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
... 7 more
org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
testGetOldestTombstoneTimeNonReplicate FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$52/1794955615.run
in VM 1 running on Host e45ce8a4541a with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
at
org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeNonReplicate(TombstoneDUnitTest.java:151)
Caused by:
java.net.BindException: Failed to create server socket on
172.17.0.20[40404]
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
at
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
at
org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
at
org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:384)
at
org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeNonReplicate$bb17a952$1(TombstoneDUnitTest.java:153)
Caused by:
java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:390)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
... 7 more
{noformat}
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/623
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8716) TombstoneDUnitTests fail with a BindException creating a cache server on the default port
[
https://issues.apache.org/jira/browse/GEODE-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8716:
-
Assignee: Mark Hanson
> TombstoneDUnitTests fail with a BindException creating a cache server on the
> default port
> -
>
> Key: GEODE-8716
> URL: https://issues.apache.org/jira/browse/GEODE-8716
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bruce J Schuchardt
>Assignee: Mark Hanson
>Priority: Major
>
> The test should be changed to do a wildcard bind (setPort(0)).
> {noformat}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneNonReplicate FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$46/1195148372.run
> in VM 1 running on Host e45ce8a4541a with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneNonReplicate(TombstoneDUnitTest.java:223)
> Caused by:
> java.net.BindException: Failed to create server socket on
> 172.17.0.20[40404]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:384)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneNonReplicate$bb17a952$1(TombstoneDUnitTest.java:225)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 7 more
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeNonReplicate FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$52/1794955615.run
> in VM 1 running on Host e45ce8a4541a with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeNonReplicate(TombstoneDUnitTest.java:151)
> Caused by:
> java.net.BindException: Failed to create server socket on
> 172.17.0.20[40404]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:384)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeNonReplicate$bb17a952$1(TombstoneDUnitTest.java:153)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(Server
[jira] [Commented] (GEODE-8716) TombstoneDUnitTests fail with a BindException creating a cache server on the default port
[
https://issues.apache.org/jira/browse/GEODE-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232891#comment-17232891
]
Geode Integration commented on GEODE-8716:
--
Seen in [DistributedTestOpenJDK8
#623|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/623]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0487/test-results/distributedTest/1605319536/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0487/test-artifacts/1605319536/distributedtestfiles-OpenJDK8-1.14.0-build.0487.tgz].
> TombstoneDUnitTests fail with a BindException creating a cache server on the
> default port
> -
>
> Key: GEODE-8716
> URL: https://issues.apache.org/jira/browse/GEODE-8716
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bruce J Schuchardt
>Assignee: Mark Hanson
>Priority: Major
>
> The test should be changed to do a wildcard bind (setPort(0)).
> {noformat}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneNonReplicate FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$46/1195148372.run
> in VM 1 running on Host e45ce8a4541a with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneNonReplicate(TombstoneDUnitTest.java:223)
> Caused by:
> java.net.BindException: Failed to create server socket on
> 172.17.0.20[40404]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:384)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneNonReplicate$bb17a952$1(TombstoneDUnitTest.java:225)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
> ... 7 more
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeNonReplicate FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$52/1794955615.run
> in VM 1 running on Host e45ce8a4541a with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeNonReplicate(TombstoneDUnitTest.java:151)
> Caused by:
> java.net.BindException: Failed to create server socket on
> 172.17.0.20[40404]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:726)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:303)
> at
> org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:427)
> at
> org.apache.geode.internal.cache.CacheServerImpl.start(Cache
[jira] [Created] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
John Hutchison created GEODE-8717: - Summary: Redis INFO Command should only return specified sections when given parameter Key: GEODE-8717 URL: https://issues.apache.org/jira/browse/GEODE-8717 Project: Geode Issue Type: Improvement Components: redis Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232893#comment-17232893
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#592|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/592]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0485/test-results/distributedTest/1605308485/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0485/test-artifacts/1605308485/distributedtestfiles-OpenJDK11-1.14.0-build.0485.tgz].
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.14.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-8713: -- Assignee: Dave Barnes > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8672) Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost
[ https://issues.apache.org/jira/browse/GEODE-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-8672. - Fix Version/s: 1.14.0 Resolution: Fixed > Concurrent transactional destroy with GII could cause an entry to be removed > and version information to be lost > --- > > Key: GEODE-8672 > URL: https://issues.apache.org/jira/browse/GEODE-8672 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In a newly rebalanced bucket, while GII is in progress, a transactional > destroy is applied to cache. There is a logic that it should be in token mode > and leaves the entry as a Destroyed token, even though the version tag of the > entry indicates that it has the correct version. > However, at end of the GII, there is a > cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed > entries – this wipes off the entry version tag information and cause the > subsequent creates starts fresh with new version tags. > This could leads to client server data inconsistency as the newly created > entries will be ignored by the clients as the newly created entry has lower > version number while client has high ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[
https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232949#comment-17232949
]
ASF GitHub Bot commented on GEODE-8711:
---
sabbey37 commented on a change in pull request #5749:
URL: https://github.com/apache/geode/pull/5749#discussion_r524387822
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/RedisCommandType.java
##
@@ -265,6 +267,9 @@
FLUSHDB(new FlushAllExecutor(), UNSUPPORTED, new
MaximumParameterRequirements(2, ERROR_SYNTAX)),
INFO(new InfoExecutor(), UNSUPPORTED, new MaximumParameterRequirements(2,
ERROR_SYNTAX)),
SHUTDOWN(new ShutDownExecutor(), UNSUPPORTED, new
MaximumParameterRequirements(2, ERROR_SYNTAX)),
+ SLOWLOG(new SlowlogExecutor(), UNSUPPORTED, new
MinimumParameterRequirements(2)
+ .and(new MaximumParameterRequirements(3, ERROR_SYNTAX))
+ .and(new SlowlogParameterRequirements())),
Review comment:
I don't think you need the `new MaximumParameterRequirements(3,
ERROR_SYNTAX)` here. In Redis, when more than 3 parameters are provided, the
following error is returned: `ERR Unknown subcommand or wrong number of
arguments for '[WHATEVER OPTION YOU TYPED]'. Try SLOWLOG HELP.` (not syntax
error).
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractSlowlogIntegrationTest.java
##
@@ -0,0 +1,117 @@
+/*
+ * 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.redis.internal.executor.server;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
+
+import java.util.List;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+import redis.clients.jedis.Jedis;
+import redis.clients.jedis.Protocol;
+import redis.clients.jedis.util.Slowlog;
+
+import org.apache.geode.test.awaitility.GeodeAwaitility;
+import org.apache.geode.test.dunit.rules.RedisPortSupplier;
+
+public abstract class AbstractSlowlogIntegrationTest implements
RedisPortSupplier {
+
+ private Jedis jedis;
+ private static final int REDIS_CLIENT_TIMEOUT =
+ Math.toIntExact(GeodeAwaitility.getTimeout().toMillis());
+
+ @Before
+ public void setUp() {
+jedis = new Jedis("localhost", getPort(), REDIS_CLIENT_TIMEOUT);
+ }
+
+ @After
+ public void tearDown() {
+jedis.close();
+ }
+
+ abstract int getExposedPort();
+
+ @Test
+ public void shouldReturnEmptyArray_whenGetSubcommandSpecified() {
+List actualResult = jedis.slowlogGet();
+
+assertThat(actualResult.size()).isEqualTo(0);
+ }
+
+ @Test
+ public void
shouldReturnEmptyArray_whenGetSubcommandSpecified_withLengthParameter() {
+List actualResult = jedis.slowlogGet(200);
+
+assertThat(actualResult.size()).isEqualTo(0);
+ }
+
+ @Test
+ public void
shouldReturnEmptyArray_whenGetSubcommandSpecified_withNegativeLengthParameter()
{
+List actualResult = jedis.slowlogGet(-200);
+
+assertThat(actualResult.size()).isEqualTo(0);
+ }
+
+ @Test
+ public void shouldReturnZero_whenLenSubcommandSpecified() {
+Long length = jedis.slowlogLen();
+
+assertThat(length).isEqualTo(0L);
+ }
+
+ @Test
+ public void shouldReturnOK_whenResetSubcommandSpecified() {
+String response = jedis.slowlogReset();
+
+assertThat(response).isEqualTo("OK");
+ }
+
+ @Test
+ public void shouldThrowException_IfResetGivenAParameter() {
+assertThatThrownBy(
+() -> jedis.sendCommand(
+Protocol.Command.SLOWLOG, "RESET", "Superfluous"))
+.hasMessageContaining("ERR Unknown subcommand or wrong number
of arguments for");
Review comment:
It would be nice to put the full error message here and verify that it
matches exactly (so `hasMessage()` vs. `hasMessageContaining()` (if we end up
returning the same messages as Redis).
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractSlowlogIntegrationTest.java
##
@@ -0,0 +1,117 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributo
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232953#comment-17232953 ] ASF GitHub Bot commented on GEODE-8706: --- boglesby commented on pull request #5750: URL: https://github.com/apache/geode/pull/5750#issuecomment-728218413 The lock is controlling access to the connection field. The destroyConnection and initializeConnection methods set it so they use the writeLock, and the readAcknowledgement and _dispatchBatch methods access it so they use the readLock. The getConnection method should also use the readLock, but it hasn't up until now with this change. 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 > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[
https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232960#comment-17232960
]
ASF GitHub Bot commented on GEODE-8706:
---
boglesby commented on a change in pull request #5750:
URL: https://github.com/apache/geode/pull/5750#discussion_r524456655
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -295,9 +301,16 @@ public Connection getConnection(boolean
startAckReaderThread) throws GatewaySend
// OR the connection's ServerLocation doesn't match with the one stored in
sender
// THEN initialize the connection
if (!this.sender.isParallel()) {
- if (this.connection == null || this.connection.isDestroyed()
- || this.connection.getServer() == null
- ||
!this.connection.getServer().equals(this.sender.getServerLocation())) {
+ boolean needToReconnect = false;
+ getConnectionLifeCycleLock().readLock().lock();
+ try {
+needToReconnect = this.connection == null ||
this.connection.isDestroyed()
+|| this.connection.getServer() == null
+||
!this.connection.getServer().equals(this.sender.getServerLocation());
+ } finally {
+getConnectionLifeCycleLock().readLock().unlock();
+ }
+ if (needToReconnect) {
if (logger.isDebugEnabled()) {
Review comment:
Does this debug statement need to be moved inside the readLock too since
it calls `this.connection.getServer()`?
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
> testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure
> in CI
> ---
>
> Key: GEODE-8706
> URL: https://issues.apache.org/jira/browse/GEODE-8706
> Project: Geode
> Issue Type: Bug
>Reporter: John Hutchison
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest
> > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run
> in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but
> actual entries: 8000 expected:<0> but was:<8000> within 5 minutes.
> Caused by:
> java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000
> expected:<0> but was:<8000>
> 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-vm4.log' at line 68
> [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following
> exception occurred while processing a batch:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232975#comment-17232975
]
ASF GitHub Bot commented on GEODE-8704:
---
sabbey37 opened a new pull request #5754:
URL: https://github.com/apache/geode/pull/5754
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
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[
https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17232977#comment-17232977
]
ASF GitHub Bot commented on GEODE-8706:
---
gesterzhou commented on a change in pull request #5750:
URL: https://github.com/apache/geode/pull/5750#discussion_r524477248
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -295,9 +301,16 @@ public Connection getConnection(boolean
startAckReaderThread) throws GatewaySend
// OR the connection's ServerLocation doesn't match with the one stored in
sender
// THEN initialize the connection
if (!this.sender.isParallel()) {
- if (this.connection == null || this.connection.isDestroyed()
- || this.connection.getServer() == null
- ||
!this.connection.getServer().equals(this.sender.getServerLocation())) {
+ boolean needToReconnect = false;
+ getConnectionLifeCycleLock().readLock().lock();
+ try {
+needToReconnect = this.connection == null ||
this.connection.isDestroyed()
+|| this.connection.getServer() == null
+||
!this.connection.getServer().equals(this.sender.getServerLocation());
+ } finally {
+getConnectionLifeCycleLock().readLock().unlock();
+ }
+ if (needToReconnect) {
if (logger.isDebugEnabled()) {
Review comment:
No need, you see the original author used:
(this.connection == null) ? "null" : ...
That means he realized this connection could be null here
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
> testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure
> in CI
> ---
>
> Key: GEODE-8706
> URL: https://issues.apache.org/jira/browse/GEODE-8706
> Project: Geode
> Issue Type: Bug
>Reporter: John Hutchison
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest
> > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run
> in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but
> actual entries: 8000 expected:<0> but was:<8000> within 5 minutes.
> Caused by:
> java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000
> expected:<0> but was:<8000>
> 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-vm4.log' at line 68
> [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following
> exception occurred while processing a batch:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8718) upgrade Shiro to 1.7.0
Owen Nichols created GEODE-8718: --- Summary: upgrade Shiro to 1.7.0 Key: GEODE-8718 URL: https://issues.apache.org/jira/browse/GEODE-8718 Project: Geode Issue Type: Bug Components: management Affects Versions: 1.13.0, 1.12.0, 1.14.0 Reporter: Owen Nichols Our current Shiro version (1.6.0) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8718) upgrade Shiro to 1.7.0
[ https://issues.apache.org/jira/browse/GEODE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233022#comment-17233022 ] ASF GitHub Bot commented on GEODE-8718: --- onichols-pivotal opened a new pull request #5755: URL: https://github.com/apache/geode/pull/5755 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 > upgrade Shiro to 1.7.0 > -- > > Key: GEODE-8718 > URL: https://issues.apache.org/jira/browse/GEODE-8718 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0, 1.13.0, 1.14.0 >Reporter: Owen Nichols >Priority: Major > > Our current Shiro version (1.6.0) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8718) upgrade Shiro to 1.7.0
[ https://issues.apache.org/jira/browse/GEODE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8718: -- Labels: pull-request-available (was: ) > upgrade Shiro to 1.7.0 > -- > > Key: GEODE-8718 > URL: https://issues.apache.org/jira/browse/GEODE-8718 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0, 1.13.0, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > Our current Shiro version (1.6.0) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[
https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233030#comment-17233030
]
ASF GitHub Bot commented on GEODE-8711:
---
sabbey37 commented on a change in pull request #5749:
URL: https://github.com/apache/geode/pull/5749#discussion_r524442295
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/server/SlowlogExecutor.java
##
@@ -30,7 +27,21 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
-List values = new ArrayList();
-return RedisResponse.array(values);
+String subCommand = command.getStringKey();
+if (subCommand.toLowerCase().equals("get")) {
+ return RedisResponse.emptyArray();
+} else if (subCommand.toLowerCase().equals("len")) {
+ return RedisResponse.integer(0);
+} else if (subCommand.toLowerCase().equals("reset")) {
+ return RedisResponse.ok();
+}
+throw new
RedisParametersMismatchException(wrongNumberOfArgumentsErrorMessage());
+ }
+
+ public String wrongNumberOfArgumentsErrorMessage() {
+String result;
+result = String
+.format("Unknown subcommand or wrong number of arguments for 'len'.
Try SLOWLOG HELP.");
+return result;
Review comment:
It seems kind of weird that we have this hard coded to `len`... right
now if I type in `slowlog sjls`, I get `ERR Unknown subcommand or wrong number
of arguments for 'len'. Try SLOWLOG HELP.` instead of `ERR Unknown subcommand
or wrong number of arguments for 'sjls'. Try SLOWLOG HELP.` It also might be
good to add this Error to the `RedisConstants` class.
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
> Enable SLOWLOG command to support Redis monitoring tools
>
>
> Key: GEODE-8711
> URL: https://issues.apache.org/jira/browse/GEODE-8711
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
>
> The Redis SLOWLOG command tracks slow-executing commands. This will implement
> a placeholder to prevent errors in tools like Datadog or Redis Insights.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8553) Reduce ThinClientLocatorHelper lock time
[ https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233031#comment-17233031 ] ASF GitHub Bot commented on GEODE-8553: --- codecov-io edited a comment on pull request #660: URL: https://github.com/apache/geode-native/pull/660#issuecomment-706753854 # [Codecov](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=h1) Report > Merging [#660](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=desc) (ebb7cb8) into [develop](https://codecov.io/gh/apache/geode-native/commit/0d9a99d5e0632de62df17921950cf3f6640efb33?el=desc) (0d9a99d) will **increase** coverage by `0.00%`. > The diff coverage is `94.65%`. [](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=tree) ```diff @@Coverage Diff@@ ## develop #660+/- ## = Coverage74.04% 74.04% = Files 644 644 Lines5118951086 -103 = - Hits 3790337828-75 + Misses 1328613258-28 ``` | [Impacted Files](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [cppcache/src/ThinClientLocatorHelper.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRMb2NhdG9ySGVscGVyLmNwcA==) | `93.87% <94.44%> (+7.76%)` | :arrow_up: | | [cppcache/src/ThinClientLocatorHelper.hpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRMb2NhdG9ySGVscGVyLmhwcA==) | `100.00% <100.00%> (ø)` | | | [cppcache/src/ThinClientPoolDM.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRQb29sRE0uY3Bw) | `76.32% <100.00%> (-0.06%)` | :arrow_down: | | [cppcache/src/ReadWriteLock.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1JlYWRXcml0ZUxvY2suY3Bw) | `62.50% <0.00%> (-18.75%)` | :arrow_down: | | [cppcache/src/PdxTypeRegistry.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1BkeFR5cGVSZWdpc3RyeS5jcHA=) | `77.94% <0.00%> (-2.21%)` | :arrow_down: | | [cppcache/src/ClientMetadataService.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0NsaWVudE1ldGFkYXRhU2VydmljZS5jcHA=) | `62.24% <0.00%> (-0.46%)` | :arrow_down: | | [cppcache/src/ThinClientRedundancyManager.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRSZWR1bmRhbmN5TWFuYWdlci5jcHA=) | `76.09% <0.00%> (-0.32%)` | :arrow_down: | | [cppcache/src/TcrConnection.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckNvbm5lY3Rpb24uY3Bw) | `72.95% <0.00%> (+0.47%)` | :arrow_up: | | [cppcache/src/TcrEndpoint.cpp](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckVuZHBvaW50LmNwcA==) | `55.11% <0.00%> (+0.56%)` | :arrow_up: | | ... and [2 more](https://codecov.io/gh/apache/geode-native/pull/660/diff?src=pr&el=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=footer). Last update [0d9a99d...ebb7cb8](https://codecov.io/gh/apache/geode-native/pull/660?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). 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 > Reduce ThinClientLocatorHelper lock time > > > Key: GEODE-8553 > URL: https://issues.apache.org/jira/browse/GEODE-8553 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.12.0, 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major >
[jira] [Created] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
Sarah Abbey created GEODE-8719:
--
Summary: 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
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
]
Sarah Abbey updated GEODE-8719:
---
Priority: Minor (was: Major)
> 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
>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-8537) Memory increases whenever LRU eviction is enabled
[
https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233053#comment-17233053
]
ASF GitHub Bot commented on GEODE-8537:
---
pdxcodemonkey commented on a change in pull request #687:
URL: https://github.com/apache/geode-native/pull/687#discussion_r524527337
##
File path: cppcache/src/LRUQueue.hpp
##
@@ -0,0 +1,100 @@
+/*
+ * 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.
+ */
+
+#pragma once
+
+#ifndef GEODE_LRUQUEUE_H_
+#define GEODE_LRUQUEUE_H_
+
+#include
+#include
+
+#include
+
+#include "util/concurrent/spinlock_mutex.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+class MapEntryImpl;
+
+/**
+ * This class holds a queue of entries sorted by its use order
+ * @note All accesses to the queue are mutually exclusive
+ */
+class LRUQueue {
Review comment:
boost::lockfree::queue, maybe? If this is just a generic thread-safe
queue implementation, we really shouldn't be writing our own. This one uses
our own hand-rolled mutex for locking, as well, which is _also_ a thing that we
should never have written, that should be removed from the codebase altogether.
##
File path: cppcache/src/EvictionController.hpp
##
@@ -75,29 +73,27 @@ class EvictionController {
void svc(void);
- void updateRegionHeapInfo(int64_t info);
- void registerRegion(const std::string& name);
- void deregisterRegion(const std::string& name);
- void evict(int32_t percentage);
+ void evict(float percentage);
+ void inc_heap_size(int64_t delta);
+ void register_region(const std::string& name);
+ void unregister_region(const std::string& name);
Review comment:
The style guide (I re-learned after reviewing it) dictates snake case
for variables and setter/getter functions, and mixed case otherwise. I prefer
the mixed case for method names, for consistency if nothing else - can we
change the instances of this in the PR?
##
File path: cppcache/src/LRUQueue.hpp
##
@@ -0,0 +1,100 @@
+/*
+ * 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.
+ */
+
+#pragma once
+
+#ifndef GEODE_LRUQUEUE_H_
+#define GEODE_LRUQUEUE_H_
+
+#include
+#include
+
+#include
+
+#include "util/concurrent/spinlock_mutex.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+class MapEntryImpl;
+
+/**
+ * This class holds a queue of entries sorted by its use order
+ * @note All accesses to the queue are mutually exclusive
+ */
+class LRUQueue {
Review comment:
Let us know if there's some reason here we can't use an off-the-shelf
queue solution. Otherwise, let's use one of those.
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
> Memory increases whenever LRU eviction is enabled
> -
>
> Key: GEODE-8537
> URL: https://issues.apache.org/jira/browse/GEODE-8537
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[
https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233057#comment-17233057
]
ASF GitHub Bot commented on GEODE-8693:
---
pdxcodemonkey commented on a change in pull request #690:
URL: https://github.com/apache/geode-native/pull/690#discussion_r524546236
##
File path: cppcache/integration/test/FunctionExecutionTest.cpp
##
@@ -251,3 +253,79 @@ TEST(FunctionExecutionTest,
OnServersWithReplicatedRegionsInPool) {
resultList[i + ON_SERVERS_TEST_REGION_ENTRIES_SIZE / 2]);
}
}
+
+void executeTestFunctionOnLoopAndExpectNotConnectedException(
+std::shared_ptr pool) {
+ // Filter on odd keys
+ auto routingObj = CacheableVector::create();
+ for (int i = 0; i < ON_SERVERS_TEST_REGION_ENTRIES_SIZE; i++) {
+if (i % 2 == 0) {
+ continue;
+}
+routingObj->push_back(CacheableString::create("KEY--" +
std::to_string(i)));
+ }
+
+ auto execution = FunctionService::onServers(pool);
+
+ ASSERT_THROW(
+ {
+while (true) {
+ // This call must eventually throw the NotConnectedException
+ auto rc =
+ execution.withArgs(routingObj).execute("MultiGetFunctionISlow");
+
+ auto executeFunctionResult = rc->getResult();
+
+ auto resultList = serverResultsToStrings(executeFunctionResult);
+
+ // Executed on 2 servers, we should have two sets of results
+ ASSERT_EQ(resultList.size(), ON_SERVERS_TEST_REGION_ENTRIES_SIZE);
+}
+ },
+ apache::geode::client::NotConnectedException);
+}
+
+TEST(FunctionExecutionTest, OnServersOneServerGoesDown) {
+ Cluster cluster{
+ LocatorCount{1}, ServerCount{2},
+ CacheXMLFiles(
+ {std::string(getFrameworkString(FrameworkVariable::TestCacheXmlDir))
+
+ "/func_cacheserver1_pool.xml",
+ std::string(getFrameworkString(FrameworkVariable::TestCacheXmlDir))
+
+ "/func_cacheserver2_pool.xml"})};
+
+ cluster.start([&]() {
+cluster.getGfsh()
+.deploy()
+.jar(getFrameworkString(FrameworkVariable::JavaObjectJarPath))
+.execute();
+ });
+
+ auto cache = CacheFactory().set("log-level", "debug").create();
+ auto poolFactory = cache.getPoolManager().createFactory();
+
+ cluster.applyLocators(poolFactory);
+
+ auto pool =
+
poolFactory.setLoadConditioningInterval(std::chrono::milliseconds::zero())
+ .setIdleTimeout(std::chrono::milliseconds::zero())
+ .create("pool");
+
+ auto region = cache.createRegionFactory(RegionShortcut::PROXY)
+.setPoolName("pool")
+.create("partition_region");
+
+ for (int i = 0; i < ON_SERVERS_TEST_REGION_ENTRIES_SIZE; i++) {
+region->put("KEY--" + std::to_string(i), "VALUE--" + std::to_string(i));
+ }
+
+ auto threadAux = std::make_shared(
+ executeTestFunctionOnLoopAndExpectNotConnectedException, pool);
+
+ // Sleep a bit to allow for some successful responses before the exception
+ sleep(5);
Review comment:
This doesn't build on Windows:
```
C:\nativeclient\cppcache\integration\test\FunctionExecutionTest.cpp(326):
error C3861: 'sleep': identifier not found
```
Looks like we use `std::this_thread::sleep_for` in the rest of the 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
> C++ native client Function.execute() with onServers does not throw exception
> if one of the servers goes down while executing the function.
> --
>
> Key: GEODE-8693
> URL: https://issues.apache.org/jira/browse/GEODE-8693
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> According to the Apache Geode Native C++ API documentation, the
> FunctionService.onServers() function will throw an Exception if one of the
> servers goes down while dispatching or executing the function on the server.
> Nevertheless, currently no exception is thrown in that case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[
https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233066#comment-17233066
]
ASF GitHub Bot commented on GEODE-8693:
---
pdxcodemonkey commented on a change in pull request #690:
URL: https://github.com/apache/geode-native/pull/690#discussion_r524547942
##
File path: cppcache/src/ExecutionImpl.cpp
##
@@ -429,33 +429,20 @@ void ExecutionImpl::executeOnAllServers(const
std::string& func,
std::shared_ptr exceptionPtr = nullptr;
GfErrType err = tcrdm->sendRequestToAllServers(
func.c_str(), getResult, timeout, m_args, m_rc, exceptionPtr);
- if (exceptionPtr != nullptr && err != GF_NOERR) {
-LOGDEBUG("Execute errorred: %d", err);
-// throw FunctionExecutionException( "Execute: failed to execute function
-// with server." );
-if (err == GF_CACHESERVER_EXCEPTION) {
- throw FunctionExecutionException(
- "Execute: failed to execute function with server.");
-} else {
- throwExceptionIfError("Execute", err);
-}
- }
-
- if (err == GF_AUTHENTICATION_FAILED_EXCEPTION ||
- err == GF_NOT_AUTHORIZED_EXCEPTION ||
- err == GF_AUTHENTICATION_REQUIRED_EXCEPTION) {
-throwExceptionIfError("Execute", err);
- }
if (err != GF_NOERR) {
+LOGDEBUG("Execute errorred: %d", err);
Review comment:
Sorry to be "that guy" about grammar, but errorred isn't really a word.
Should be "erred" or just avoid it altogether and use "failed". Thx
##
File path: cppcache/src/ExecutionImpl.cpp
##
@@ -429,33 +429,20 @@ void ExecutionImpl::executeOnAllServers(const
std::string& func,
std::shared_ptr exceptionPtr = nullptr;
GfErrType err = tcrdm->sendRequestToAllServers(
func.c_str(), getResult, timeout, m_args, m_rc, exceptionPtr);
- if (exceptionPtr != nullptr && err != GF_NOERR) {
-LOGDEBUG("Execute errorred: %d", err);
-// throw FunctionExecutionException( "Execute: failed to execute function
-// with server." );
-if (err == GF_CACHESERVER_EXCEPTION) {
- throw FunctionExecutionException(
- "Execute: failed to execute function with server.");
-} else {
- throwExceptionIfError("Execute", err);
-}
- }
-
- if (err == GF_AUTHENTICATION_FAILED_EXCEPTION ||
- err == GF_NOT_AUTHORIZED_EXCEPTION ||
- err == GF_AUTHENTICATION_REQUIRED_EXCEPTION) {
-throwExceptionIfError("Execute", err);
- }
if (err != GF_NOERR) {
+LOGDEBUG("Execute errorred: %d", err);
Review comment:
Ugh, and it was even like this to begin with - yikes, sorry.
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 Function.execute() with onServers does not throw exception
> if one of the servers goes down while executing the function.
> --
>
> Key: GEODE-8693
> URL: https://issues.apache.org/jira/browse/GEODE-8693
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> According to the Apache Geode Native C++ API documentation, the
> FunctionService.onServers() function will throw an Exception if one of the
> servers goes down while dispatching or executing the function on the server.
> Nevertheless, currently no exception is thrown in that case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233069#comment-17233069 ] ASF GitHub Bot commented on GEODE-8693: --- codecov-io commented on pull request #690: URL: https://github.com/apache/geode-native/pull/690#issuecomment-728320149 # [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=h1) Report > Merging [#690](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=desc) (bf89d76) into [develop](https://codecov.io/gh/apache/geode-native/commit/5c7d47d34c2b8a53874ec6f53e66c2290fd0427c?el=desc) (5c7d47d) will **decrease** coverage by `0.07%`. > The diff coverage is `54.54%`. [](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) ```diff @@ Coverage Diff @@ ## develop #690 +/- ## === - Coverage74.12% 74.04% -0.08% === Files 644 644 Lines5118751184 -3 === - Hits 3794237899 -43 - Misses 1324513285 +40 ``` | [Impacted Files](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [cppcache/src/ExecutionImpl.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0V4ZWN1dGlvbkltcGwuY3Bw) | `69.92% <28.57%> (+1.84%)` | :arrow_up: | | [cppcache/src/ThinClientPoolDM.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRQb29sRE0uY3Bw) | `76.71% <100.00%> (+0.23%)` | :arrow_up: | | [cppcache/src/ReadWriteLock.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1JlYWRXcml0ZUxvY2suY3Bw) | `81.25% <0.00%> (-18.75%)` | :arrow_down: | | [...tion-test/testThinClientRemoteQueryFailoverPdx.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvaW50ZWdyYXRpb24tdGVzdC90ZXN0VGhpbkNsaWVudFJlbW90ZVF1ZXJ5RmFpbG92ZXJQZHguY3Bw) | `85.48% <0.00%> (-4.04%)` | :arrow_down: | | [cppcache/src/TcrEndpoint.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckVuZHBvaW50LmNwcA==) | `54.27% <0.00%> (-2.39%)` | :arrow_down: | | [cppcache/src/PdxTypeRegistry.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1BkeFR5cGVSZWdpc3RyeS5jcHA=) | `77.94% <0.00%> (-2.21%)` | :arrow_down: | | [cppcache/src/TXCommitMessage.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RYQ29tbWl0TWVzc2FnZS5jcHA=) | `74.50% <0.00%> (-1.97%)` | :arrow_down: | | [cppcache/src/TcrConnection.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckNvbm5lY3Rpb24uY3Bw) | `72.48% <0.00%> (-1.26%)` | :arrow_down: | | [cppcache/src/ClientMetadataService.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0NsaWVudE1ldGFkYXRhU2VydmljZS5jcHA=) | `61.78% <0.00%> (-1.15%)` | :arrow_down: | | [...tegration-test/testThinClientRemoteRegionQuery.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvaW50ZWdyYXRpb24tdGVzdC90ZXN0VGhpbkNsaWVudFJlbW90ZVJlZ2lvblF1ZXJ5LmNwcA==) | `82.33% <0.00%> (-1.13%)` | :arrow_down: | | ... and [8 more](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=footer). Last update [5c7d47d...bf89d76](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). 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 Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > ---
[jira] [Commented] (GEODE-8715) Redis INFO command 'Keyspace' section should not be present if no keys in database
[ https://issues.apache.org/jira/browse/GEODE-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233072#comment-17233072 ] ASF GitHub Bot commented on GEODE-8715: --- sabbey37 merged pull request #5753: URL: https://github.com/apache/geode/pull/5753 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 > Redis INFO command 'Keyspace' section should not be present if no keys in > database > -- > > Key: GEODE-8715 > URL: https://issues.apache.org/jira/browse/GEODE-8715 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233074#comment-17233074 ] ASF subversion and git services commented on GEODE-8706: Commit 1bf18b2e9d3bee8c75ec2acb2331a6c12cc886b6 in geode's branch refs/heads/develop from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bf18b2 ] GEODE-8706: Redis INFO command 'Keyspace' section should not be present if no keys in database (#5753) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233076#comment-17233076 ] ASF subversion and git services commented on GEODE-8706: Commit 1bf18b2e9d3bee8c75ec2acb2331a6c12cc886b6 in geode's branch refs/heads/develop from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bf18b2 ] GEODE-8706: Redis INFO command 'Keyspace' section should not be present if no keys in database (#5753) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[
https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233082#comment-17233082
]
ASF GitHub Bot commented on GEODE-8537:
---
gaussianrecurrence commented on a change in pull request #687:
URL: https://github.com/apache/geode-native/pull/687#discussion_r524585761
##
File path: cppcache/src/LRUQueue.hpp
##
@@ -0,0 +1,100 @@
+/*
+ * 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.
+ */
+
+#pragma once
+
+#ifndef GEODE_LRUQUEUE_H_
+#define GEODE_LRUQUEUE_H_
+
+#include
+#include
+
+#include
+
+#include "util/concurrent/spinlock_mutex.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+class MapEntryImpl;
+
+/**
+ * This class holds a queue of entries sorted by its use order
+ * @note All accesses to the queue are mutually exclusive
+ */
+class LRUQueue {
Review comment:
Regarding why it is needed a custom written queue. There are several
reason why:
1. I wanted to encapsulate LRUProperties iterator management inside a class,
so any code using the LRUQueue does not have to take care of that.
2. Usually, queues does not allow to remove entries at a random position,
which would not make possible to clear deleted entries, which is the whole
point of this PR.
3. There is no queue implementation that allows to take an entry and move it
to its end.
What I am not sure about is wether to use a spinlock, an standard mutex or
put some effort and try to write a completly lock-free thread-safe LRU queue :S
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
> Memory increases whenever LRU eviction is enabled
> -
>
> Key: GEODE-8537
> URL: https://issues.apache.org/jira/browse/GEODE-8537
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: massif-8419.png, massif.out.8419
>
>
> *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml
> for a region
> *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region
> region
> *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region
> region
> *HAVING* configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications
> *THEN* memory increases continously over time, even going over the LRU limit.
> Find massif tool report as massif.out.8419 showing the memory increase.
> Also this is a capture of massif-visualizer for the report:
> !massif-8419.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233090#comment-17233090
]
ASF GitHub Bot commented on GEODE-8623:
---
pivotal-jbarrett commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r524600339
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ private static final SteadyTimer steadyClock = new SteadyTimer();
/**
* Try the supplier function until the predicate is true or timeout occurs.
*
* @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
* @param interval time between each try
- * @param timeUnit to retry for
+ * @param intervalUnit the unit for interval
* @param supplier to execute until predicate is true or times out
* @param predicate to test for retry
* @param type of return value
* @return value from supplier after it passes predicate or times out.
*/
- public static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
The last iteration is the problem, why sleep to delay the return. Either
just return because it would timeout at its regular interval or reduce the
interval and try again before timing out. Either way there is no point I
delaying the results in the last iteration as this implementation does.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEv
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[
https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233099#comment-17233099
]
ASF GitHub Bot commented on GEODE-8693:
---
echobravopapa commented on a change in pull request #690:
URL: https://github.com/apache/geode-native/pull/690#discussion_r524592099
##
File path: cppcache/src/ThinClientPoolDM.cpp
##
@@ -2414,7 +2415,7 @@ GfErrType FunctionExecution::execute() {
m_error = m_poolDM->sendRequestToEP(request, reply, m_ep);
m_error = m_poolDM->handleEPError(m_ep, reply, m_error);
if (m_error != GF_NOERR) {
-if (m_error == GF_NOTCON || m_error == GF_IOERR) {
+if (m_error == GF_NOTCON) {
Review comment:
how did you determine we no longer need to check for`GF_IOERR`?
##
File path: cppcache/src/ThinClientPoolDM.cpp
##
@@ -670,11 +670,12 @@ GfErrType ThinClientPoolDM::sendRequestToAllServers(
err == GF_NOT_AUTHORIZED_EXCEPTION ||
err == GF_AUTHENTICATION_REQUIRED_EXCEPTION) {
finalErrorReturn = err;
-} else if (!(finalErrorReturn == GF_AUTHENTICATION_FAILED_EXCEPTION ||
- finalErrorReturn == GF_NOT_AUTHORIZED_EXCEPTION ||
- finalErrorReturn ==
- GF_AUTHENTICATION_REQUIRED_EXCEPTION)) // returning auth
- // errors
+} else if ((err != GF_NOERR) &&
Review comment:
the check for `!GF_NOERR` looks like a good addition
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 Function.execute() with onServers does not throw exception
> if one of the servers goes down while executing the function.
> --
>
> Key: GEODE-8693
> URL: https://issues.apache.org/jira/browse/GEODE-8693
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> According to the Apache Geode Native C++ API documentation, the
> FunctionService.onServers() function will throw an Exception if one of the
> servers goes down while dispatching or executing the function on the server.
> Nevertheless, currently no exception is thrown in that case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233102#comment-17233102
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r524615847
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ private static final SteadyTimer steadyClock = new SteadyTimer();
/**
* Try the supplier function until the predicate is true or timeout occurs.
*
* @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
* @param interval time between each try
- * @param timeUnit to retry for
+ * @param intervalUnit the unit for interval
* @param supplier to execute until predicate is true or times out
* @param predicate to test for retry
* @param type of return value
* @return value from supplier after it passes predicate or times out.
*/
- public static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
what I am saying is that even it reduces the interval it wouldn't try
again, it will always just throw TimeoutException in the end.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.ge
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233108#comment-17233108 ] ASF GitHub Bot commented on GEODE-8706: --- gesterzhou merged pull request #5750: URL: https://github.com/apache/geode/pull/5750 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 > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233109#comment-17233109 ] ASF subversion and git services commented on GEODE-8706: Commit 399b875b493060d4acff0d1b41bdb37401181439 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=399b875 ] GEODE-8706: getConnection should get readLock to sync with destroyCon… (#5750) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8706. -- Fix Version/s: 1.14.0 Resolution: Fixed > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233113#comment-17233113
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r524634772
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ private static final SteadyTimer steadyClock = new SteadyTimer();
/**
* Try the supplier function until the predicate is true or timeout occurs.
*
* @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
* @param interval time between each try
- * @param timeUnit to retry for
+ * @param intervalUnit the unit for interval
* @param supplier to execute until predicate is true or times out
* @param predicate to test for retry
* @param type of return value
* @return value from supplier after it passes predicate or times out.
*/
- public static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
The example @jinmeiliao gave covers use-cases where the number of
iterations is potentially large. Those are cases where time to run predicate +
time to run supplier + sleep _interval_ << _timeout_.
There are other use-cases where that relation does not hold. In those cases
perhaps we will only execute the body of the loop once. Imagine time to run
predicate + time to run supplier + sleep _interval_ === _timeout_ i.e. the
timeout interval is roughly of the same magnitude as the other work to be done
each time through the loop. In that case, @pivotal-jbarrett's concern about
overshooting the timeout seem more important. This second scenario seems to me
to be worth the effort of the added complexity of calculating `sleepTime =
min(interval, until - now)` and returning immediately if that's
less-than-or-equal-to zero.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagem
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233114#comment-17233114
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r524634772
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ private static final SteadyTimer steadyClock = new SteadyTimer();
/**
* Try the supplier function until the predicate is true or timeout occurs.
*
* @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
* @param interval time between each try
- * @param timeUnit to retry for
+ * @param intervalUnit the unit for interval
* @param supplier to execute until predicate is true or times out
* @param predicate to test for retry
* @param type of return value
* @return value from supplier after it passes predicate or times out.
*/
- public static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
The example @jinmeiliao gave covers use-cases where the number of
iterations is potentially large. Those are cases where time to run predicate +
time to run supplier + sleep _interval_ << _timeout_.
There are other use-cases where that relation does not hold. In those cases
perhaps we will only execute the body of the loop once. Imagine time to run
predicate + time to run supplier + sleep _interval_ (=roughly-equal-to=)
_timeout_ i.e. the timeout interval is roughly of the same magnitude as the
other work to be done each time through the loop. In that case,
@pivotal-jbarrett's concern about overshooting the timeout seem more important.
This second scenario seems to me to be worth the effort of the added complexity
of calculating `sleepTime = min(interval, until - now)` and returning
immediately if that's less-than-or-equal-to zero.
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
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.inter
[jira] [Commented] (GEODE-8702) Add StringPrefixPartitionResolver
[ https://issues.apache.org/jira/browse/GEODE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233119#comment-17233119 ] Ernest Burghardt commented on GEODE-8702: - [~gaussianrecurrence] I'm curious what the use case for this is aside from parity with Java API... > Add StringPrefixPartitionResolver > - > > Key: GEODE-8702 > URL: https://issues.apache.org/jira/browse/GEODE-8702 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to have StringPrefixPartitionResolver implemented > *SO THAT* so I can just use it as for the Java API is done -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8694) Use fork of Redis in Gemfire org to run Redis tests in CI
[ https://issues.apache.org/jira/browse/GEODE-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233117#comment-17233117 ] ASF GitHub Bot commented on GEODE-8694: --- nonbinaryprogrammer commented on a change in pull request #5732: URL: https://github.com/apache/geode/pull/5732#discussion_r524645049 ## File path: ci/scripts/execute_redis_tests.sh ## @@ -19,12 +19,14 @@ cd .. -# We are currently using a personal fork for this repo because our code does not implement all +# We are currently using a patched version of this repo because our code does not implement all # Redis commands. Once all commands needed to run relevant test files are implemented, we hope to -# use Redis's repo instead. -git clone --config transfer.fsckObjects=false https://github.com/prettyClouds/redis.git +# use Redis's repo without a patch. +git clone --config transfer.fsckObjects=false https://github.com/redis/redis.git +cp geode-redis/src/acceptanceTest/resources/0001-configure-redis-tests.patch redis cd redis -git checkout tests-geode-redis +git checkout origin/5.0 +git am < 0001-configure-redis-tests.patch Review comment: thanks @sabbey37! I'll do some more testing on that 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 > Use fork of Redis in Gemfire org to run Redis tests in CI > - > > Key: GEODE-8694 > URL: https://issues.apache.org/jira/browse/GEODE-8694 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Helena Bales >Priority: Trivial > Labels: pull-request-available > > Currently, we are using a contributor's personal fork of Redis to run tests > against Geode Redis in CI. This should be switched to the fork of Redis in > the Gemfire org. Ideally, we will eventually be able to run tests from the > root Redis repo (currently we are unable to since we are not implementing all > the necessary commands). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8702) Add StringPrefixPartitionResolver
[ https://issues.apache.org/jira/browse/GEODE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233129#comment-17233129 ] Mario Salazar de Torres edited comment on GEODE-8702 at 11/16/20, 10:09 PM: Hi [~echobravo], Mainly parity with Java API. Basically, if you can specify a PartitionResolver in the server side, it makes sense that this very PartitionResolver is available in all the client APIs. Otherwise, each user of geode-native will have to maintain its own implementation of StringPrefixPartitionResolver. was (Author: gaussianrecurrence): Hi [~echobravo], Mainly parity with Java API. Basically, if you can specify a PartitionResolver in the server side, it makes sense that this very PartitionResolver is available in all the client APIs. Otherwise, each user of geode-native will have to maintain its own implementation of StringPrefixPartitionResolver. BR, Mario. > Add StringPrefixPartitionResolver > - > > Key: GEODE-8702 > URL: https://issues.apache.org/jira/browse/GEODE-8702 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to have StringPrefixPartitionResolver implemented > *SO THAT* so I can just use it as for the Java API is done -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8702) Add StringPrefixPartitionResolver
[ https://issues.apache.org/jira/browse/GEODE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233129#comment-17233129 ] Mario Salazar de Torres commented on GEODE-8702: Hi [~echobravo], Mainly parity with Java API. Basically, if you can specify a PartitionResolver in the server side, it makes sense that this very PartitionResolver is available in all the client APIs. Otherwise, each user of geode-native will have to maintain its own implementation of StringPrefixPartitionResolver. BR, Mario. > Add StringPrefixPartitionResolver > - > > Key: GEODE-8702 > URL: https://issues.apache.org/jira/browse/GEODE-8702 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to have StringPrefixPartitionResolver implemented > *SO THAT* so I can just use it as for the Java API is done -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8713: -- Labels: pull-request-available (was: ) > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233159#comment-17233159 ] ASF GitHub Bot commented on GEODE-8713: --- davebarnes97 merged pull request #694: URL: https://github.com/apache/geode-native/pull/694 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 > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233305#comment-17233305
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo commented on pull request #693:
URL: https://github.com/apache/geode-native/pull/693#issuecomment-728731731
I'm trying to write a test for this, as I reproduce it manually. There are
steps to reproduce the issue:
1. Start locator and three servers.
2. Run some puts and then run containsKeyOnServer function with transactions.
3. While containsKeyOnServer is executing kill lead server.
4. You will got UnknownException without this change.
So if you have some idea how to do this containsKeyOnServer and killing
server lead in parallel, it will help a lot.
@echobravopapa , yes, I intend this to be a draft.
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 in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerCo
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233311#comment-17233311
]
ASF subversion and git services commented on GEODE-8692:
Commit c99087aeb19abfb5bbd57036349870a6d784df1a in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c99087a ]
GEODE-8692: ArrayIndexOutOfBoundsException may be thrown in
RegionAdvisor.processProfilesQueuedDuringInitialization (#5722)
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233313#comment-17233313
]
ASF subversion and git services commented on GEODE-8664:
Commit f23e01a32213245dc684b417d97a14cf5a026741 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f23e01a ]
Revert "GEODE-8664: Nest errors in DistributionImpl.start (#5725)" (#5742)
This reverts commit f6605e0820ba9b858b8128cd31a03a29067b7710.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233314#comment-17233314
]
ASF subversion and git services commented on GEODE-8704:
Commit 8f8cc7b62be9e7d3a20f18e38fe2cff3228a55bb in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8f8cc7b ]
GEODE-8704: many CI failures in Jetty9CachingClientServerTest (#5745)
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233321#comment-17233321 ] ASF subversion and git services commented on GEODE-8706: Commit 399b875b493060d4acff0d1b41bdb37401181439 in geode's branch refs/heads/feature/GEODE-8444 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=399b875 ] GEODE-8706: getConnection should get readLock to sync with destroyCon… (#5750) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233319#comment-17233319
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233316#comment-17233316
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233318#comment-17233318
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8672) Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost
[ https://issues.apache.org/jira/browse/GEODE-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233315#comment-17233315 ] ASF subversion and git services commented on GEODE-8672: Commit 7a55cba21cbe1fd22668c014a8a96ff161a75820 in geode's branch refs/heads/feature/GEODE-8444 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7a55cba ] GEODE-8672: No need in token mode if concurrencyChecksEnabled (#5746) * The DESTROYED token is only needed to prevent concurrent destroy op is lost in GII. If concurrency checks are enabled, the version tag should be able to prevent the destroy op being lost. * Correctly set the inTokenMode to avoid a potential hang in replicate region as invokeTXCallbacks needs to wait for the region initialization finished, but region intialization could not due to lock held by threads invoking callbacks. > Concurrent transactional destroy with GII could cause an entry to be removed > and version information to be lost > --- > > Key: GEODE-8672 > URL: https://issues.apache.org/jira/browse/GEODE-8672 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In a newly rebalanced bucket, while GII is in progress, a transactional > destroy is applied to cache. There is a logic that it should be in token mode > and leaves the entry as a Destroyed token, even though the version tag of the > entry indicates that it has the correct version. > However, at end of the GII, there is a > cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed > entries – this wipes off the entry version tag information and cause the > subsequent creates starts fresh with new version tags. > This could leads to client server data inconsistency as the newly created > entries will be ignored by the clients as the newly created entry has lower > version number while client has high ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233317#comment-17233317
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233320#comment-17233320 ] ASF subversion and git services commented on GEODE-8706: Commit 1bf18b2e9d3bee8c75ec2acb2331a6c12cc886b6 in geode's branch refs/heads/feature/GEODE-8444 from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bf18b2 ] GEODE-8706: Redis INFO command 'Keyspace' section should not be present if no keys in database (#5753) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8444) When requester's RVV equals provider's rvvGC, should do fullGII
[ https://issues.apache.org/jira/browse/GEODE-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233322#comment-17233322 ] ASF subversion and git services commented on GEODE-8444: Commit 86d34d8f6c631580ce7d0e69ef6c9c3be8b7dfd0 in geode's branch refs/heads/feature/GEODE-8444 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=86d34d8 ] GEODE-8444: When requester's RVV equals provider's rvvGC, should do fullGII > When requester's RVV equals provider's rvvGC, should do fullGII > > > Key: GEODE-8444 > URL: https://issues.apache.org/jira/browse/GEODE-8444 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In current design, when requester's RVV equals provider's rvvGC, we treated > as dominated. > But if the last operation at provider is a destroy and the tombstone is GCed > when requester is offline, the provider lost the information about this key > when GII. So we should do fullGII instead of deltaGII in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233312#comment-17233312
]
ASF subversion and git services commented on GEODE-8664:
Commit f6605e0820ba9b858b8128cd31a03a29067b7710 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6605e0 ]
GEODE-8664: Nest errors in DistributionImpl.start (#5725)
- If while calling DistributionImpl.start there was either a
MembershipConfigurationException or MemberStartupException exceptions, its
original cause was not propagated, therefore being unable to properly
tackle issues on startup.
- This commit propagates both exceptions.
- Also 2 junit test were added to make sure this is working.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocat
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233329#comment-17233329
]
ASF subversion and git services commented on GEODE-8664:
Commit f6605e0820ba9b858b8128cd31a03a29067b7710 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6605e0 ]
GEODE-8664: Nest errors in DistributionImpl.start (#5725)
- If while calling DistributionImpl.start there was either a
MembershipConfigurationException or MemberStartupException exceptions, its
original cause was not propagated, therefore being unable to properly
tackle issues on startup.
- This commit propagates both exceptions.
- Also 2 junit test were added to make sure this is working.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocat
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1725#comment-1725
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233328#comment-17233328
]
ASF subversion and git services commented on GEODE-8692:
Commit c99087aeb19abfb5bbd57036349870a6d784df1a in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c99087a ]
GEODE-8692: ArrayIndexOutOfBoundsException may be thrown in
RegionAdvisor.processProfilesQueuedDuringInitialization (#5722)
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8672) Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost
[ https://issues.apache.org/jira/browse/GEODE-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1722#comment-1722 ] ASF subversion and git services commented on GEODE-8672: Commit 7a55cba21cbe1fd22668c014a8a96ff161a75820 in geode's branch refs/heads/feature/GEODE-8444 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7a55cba ] GEODE-8672: No need in token mode if concurrencyChecksEnabled (#5746) * The DESTROYED token is only needed to prevent concurrent destroy op is lost in GII. If concurrency checks are enabled, the version tag should be able to prevent the destroy op being lost. * Correctly set the inTokenMode to avoid a potential hang in replicate region as invokeTXCallbacks needs to wait for the region initialization finished, but region intialization could not due to lock held by threads invoking callbacks. > Concurrent transactional destroy with GII could cause an entry to be removed > and version information to be lost > --- > > Key: GEODE-8672 > URL: https://issues.apache.org/jira/browse/GEODE-8672 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In a newly rebalanced bucket, while GII is in progress, a transactional > destroy is applied to cache. There is a logic that it should be in token mode > and leaves the entry as a Destroyed token, even though the version tag of the > entry indicates that it has the correct version. > However, at end of the GII, there is a > cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed > entries – this wipes off the entry version tag information and cause the > subsequent creates starts fresh with new version tags. > This could leads to client server data inconsistency as the newly created > entries will be ignored by the clients as the newly created entry has lower > version number while client has high ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1723#comment-1723
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1726#comment-1726
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1727#comment-1727 ] ASF subversion and git services commented on GEODE-8706: Commit 1bf18b2e9d3bee8c75ec2acb2331a6c12cc886b6 in geode's branch refs/heads/feature/GEODE-8444 from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bf18b2 ] GEODE-8706: Redis INFO command 'Keyspace' section should not be present if no keys in database (#5753) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1721#comment-1721
]
ASF subversion and git services commented on GEODE-8704:
Commit 8f8cc7b62be9e7d3a20f18e38fe2cff3228a55bb in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8f8cc7b ]
GEODE-8704: many CI failures in Jetty9CachingClientServerTest (#5745)
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1720#comment-1720
]
ASF subversion and git services commented on GEODE-8664:
Commit f23e01a32213245dc684b417d97a14cf5a026741 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f23e01a ]
Revert "GEODE-8664: Nest errors in DistributionImpl.start (#5725)" (#5742)
This reverts commit f6605e0820ba9b858b8128cd31a03a29067b7710.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1724#comment-1724
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8444) When requester's RVV equals provider's rvvGC, should do fullGII
[ https://issues.apache.org/jira/browse/GEODE-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1729#comment-1729 ] ASF subversion and git services commented on GEODE-8444: Commit 86d34d8f6c631580ce7d0e69ef6c9c3be8b7dfd0 in geode's branch refs/heads/feature/GEODE-8444 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=86d34d8 ] GEODE-8444: When requester's RVV equals provider's rvvGC, should do fullGII > When requester's RVV equals provider's rvvGC, should do fullGII > > > Key: GEODE-8444 > URL: https://issues.apache.org/jira/browse/GEODE-8444 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In current design, when requester's RVV equals provider's rvvGC, we treated > as dominated. > But if the last operation at provider is a destroy and the tombstone is GCed > when requester is offline, the provider lost the information about this key > when GII. So we should do fullGII instead of deltaGII in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1728#comment-1728 ] ASF subversion and git services commented on GEODE-8706: Commit 399b875b493060d4acff0d1b41bdb37401181439 in geode's branch refs/heads/feature/GEODE-8444 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=399b875 ] GEODE-8706: getConnection should get readLock to sync with destroyCon… (#5750) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233345#comment-17233345
]
ASF subversion and git services commented on GEODE-8664:
Commit f23e01a32213245dc684b417d97a14cf5a026741 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f23e01a ]
Revert "GEODE-8664: Nest errors in DistributionImpl.start (#5725)" (#5742)
This reverts commit f6605e0820ba9b858b8128cd31a03a29067b7710.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.
[jira] [Commented] (GEODE-8692) ArrayIndexOutOfBoundsException may be thrown in RegionAdvisor.processProfilesQueuedDuringInitialization
[
https://issues.apache.org/jira/browse/GEODE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233343#comment-17233343
]
ASF subversion and git services commented on GEODE-8692:
Commit c99087aeb19abfb5bbd57036349870a6d784df1a in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c99087a ]
GEODE-8692: ArrayIndexOutOfBoundsException may be thrown in
RegionAdvisor.processProfilesQueuedDuringInitialization (#5722)
> ArrayIndexOutOfBoundsException may be thrown in
> RegionAdvisor.processProfilesQueuedDuringInitialization
> ---
>
> Key: GEODE-8692
> URL: https://issues.apache.org/jira/browse/GEODE-8692
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> If {{RegionAdvisor.buckets == null}} at the time the value of {{serials}} is
> generated, an {{ArrayIndexOutOfBoundsException}} may be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization}} if buckets have
> been initialized at that point.
> Code where {{ArrayIndexOutOfBoundsException}} might be thrown in
> {{RegionAdvisor.processProfilesQueuedDuringInitialization():}}
> {code:java}
> for (int i = 0; i < buckets.length; i++) {
> BucketAdvisor ba = buckets[i].getBucketAdvisor();
> int serial = qbp.serials[i]; <<< Exception thrown here
> if (serial != ILLEGAL_SERIAL) {
> ba.removeIdWithSerial(qbp.memberId, serial, qbp.destroyed);
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233344#comment-17233344
]
ASF subversion and git services commented on GEODE-8664:
Commit f6605e0820ba9b858b8128cd31a03a29067b7710 in geode's branch
refs/heads/feature/GEODE-8444 from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6605e0 ]
GEODE-8664: Nest errors in DistributionImpl.start (#5725)
- If while calling DistributionImpl.start there was either a
MembershipConfigurationException or MemberStartupException exceptions, its
original cause was not propagated, therefore being unable to properly
tackle issues on startup.
- This commit propagates both exceptions.
- Also 2 junit test were added to make sure this is working.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocat
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233348#comment-17233348
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8444) When requester's RVV equals provider's rvvGC, should do fullGII
[ https://issues.apache.org/jira/browse/GEODE-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233354#comment-17233354 ] ASF subversion and git services commented on GEODE-8444: Commit 86d34d8f6c631580ce7d0e69ef6c9c3be8b7dfd0 in geode's branch refs/heads/feature/GEODE-8444 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=86d34d8 ] GEODE-8444: When requester's RVV equals provider's rvvGC, should do fullGII > When requester's RVV equals provider's rvvGC, should do fullGII > > > Key: GEODE-8444 > URL: https://issues.apache.org/jira/browse/GEODE-8444 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In current design, when requester's RVV equals provider's rvvGC, we treated > as dominated. > But if the last operation at provider is a destroy and the tombstone is GCed > when requester is offline, the provider lost the information about this key > when GII. So we should do fullGII instead of deltaGII in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233353#comment-17233353 ] ASF subversion and git services commented on GEODE-8706: Commit 399b875b493060d4acff0d1b41bdb37401181439 in geode's branch refs/heads/feature/GEODE-8444 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=399b875 ] GEODE-8706: getConnection should get readLock to sync with destroyCon… (#5750) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233346#comment-17233346
]
ASF subversion and git services commented on GEODE-8704:
Commit 8f8cc7b62be9e7d3a20f18e38fe2cff3228a55bb in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8f8cc7b ]
GEODE-8704: many CI failures in Jetty9CachingClientServerTest (#5745)
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233350#comment-17233350
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8672) Concurrent transactional destroy with GII could cause an entry to be removed and version information to be lost
[ https://issues.apache.org/jira/browse/GEODE-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233347#comment-17233347 ] ASF subversion and git services commented on GEODE-8672: Commit 7a55cba21cbe1fd22668c014a8a96ff161a75820 in geode's branch refs/heads/feature/GEODE-8444 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7a55cba ] GEODE-8672: No need in token mode if concurrencyChecksEnabled (#5746) * The DESTROYED token is only needed to prevent concurrent destroy op is lost in GII. If concurrency checks are enabled, the version tag should be able to prevent the destroy op being lost. * Correctly set the inTokenMode to avoid a potential hang in replicate region as invokeTXCallbacks needs to wait for the region initialization finished, but region intialization could not due to lock held by threads invoking callbacks. > Concurrent transactional destroy with GII could cause an entry to be removed > and version information to be lost > --- > > Key: GEODE-8672 > URL: https://issues.apache.org/jira/browse/GEODE-8672 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In a newly rebalanced bucket, while GII is in progress, a transactional > destroy is applied to cache. There is a logic that it should be in token mode > and leaves the entry as a Destroyed token, even though the version tag of the > entry indicates that it has the correct version. > However, at end of the GII, there is a > cleanUpDestroyedTokensAndMarkGIIComplete method removes all the destroyed > entries – this wipes off the entry version tag information and cause the > subsequent creates starts fresh with new version tags. > This could leads to client server data inconsistency as the newly created > entries will be ignored by the clients as the newly created entry has lower > version number while client has high ones. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8706) testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure in CI
[ https://issues.apache.org/jira/browse/GEODE-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233352#comment-17233352 ] ASF subversion and git services commented on GEODE-8706: Commit 1bf18b2e9d3bee8c75ec2acb2331a6c12cc886b6 in geode's branch refs/heads/feature/GEODE-8444 from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bf18b2 ] GEODE-8706: Redis INFO command 'Keyspace' section should not be present if no keys in database (#5753) > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode failure > in CI > --- > > Key: GEODE-8706 > URL: https://issues.apache.org/jira/browse/GEODE-8706 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > __org.apache.geode.internal.cache.wan.offheap.SerialWANPropagationOffHeapDUnitTest > > testReplicatedSerialPropagationWithRemoteReceiverRestartedOnOtherNode > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.wan.serial.SerialWANPropagationDUnitTest$$Lambda$181/1328086690.run > in VM 4 running on Host 3e4042fb1cd7 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 java.util.Set, java.util.Setint Expected queue entries: 0 but > actual entries: 8000 expected:<0> but was:<8000> within 5 minutes. > Caused by: > java.lang.AssertionError: Expected queue entries: 0 but actual entries: 8000 > expected:<0> but was:<8000> > 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-vm4.log' at line 68 > [fatal 2020/11/13 18:09:30.989 GMT for GatewaySender_ln> tid=619] Stopping the processor because the following > exception occurred while processing a batch: > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:299) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.readAcknowledgement(GatewaySenderEventRemoteDispatcher.java:107) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:605) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8697) Propagate ForcedDisconnectException to the user application in a network partition scenario
[
https://issues.apache.org/jira/browse/GEODE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233351#comment-17233351
]
ASF subversion and git services commented on GEODE-8697:
Commit 403e19c0a2b85369274e8254c16e0ae508b82e94 in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=403e19c ]
GEODE-8697: Propagate ForcedDisconnectException to the user application (#5739)
* GEODE-8697: Propagate ForcedDisconnectException to the user application
avoid setting MemberDisconnectedException as a rootCause in
ClusterDistributionManager, even temporarily, as it's an internal
exception that should not be exposed to applications.
* addressing Ernie's comments
> Propagate ForcedDisconnectException to the user application in a network
> partition scenario
> ---
>
> Key: GEODE-8697
> URL: https://issues.apache.org/jira/browse/GEODE-8697
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Kamilla Aslami
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> During network partitioning, we expect that the coordinator closes its
> cluster with a ForcedDisconnectException. However, in some cases, threads end
> up with a MemberDisconnectedException.
> System logs show that a ForcedDisconnect has happened:
> {code:java}
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2007)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1422)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1327)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748){code}
> But it is never propagated upwards to the user application:
> {code:java}
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected., caused by
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> 10.32.111.185(gemfire3_host1_7340:7340:locator):41000 has declared
> that a network partition has occurred
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:978)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1679)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:600)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:824)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterrup
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233361#comment-17233361
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233362#comment-17233362
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8670) ReconnectDUnitTest is hiding a NullPointerException
[
https://issues.apache.org/jira/browse/GEODE-8670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233349#comment-17233349
]
ASF subversion and git services commented on GEODE-8670:
Commit 99e7a138064419c9a676411252e64077c2a1180f in geode's branch
refs/heads/feature/GEODE-8444 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=99e7a13 ]
GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException (#5744)
* GEODE-8670: ReconnectDUnitTest is hiding a NullPointerException
1. Fixed all of the IgnorableException problems in ReconnectDUnitTest
2. Modified InternalLocator to avoid throwing a NullPointerException and
added a test for this change
* fixing invalid test - had to move it to a new class to use SystemOutRule
the rule wasn't working for some reason when I added it to
InternalLocatorIntegrationTest
* removed use of SystemOutRule, which wasn't working in Stress tests
> ReconnectDUnitTest is hiding a NullPointerException
> ---
>
> Key: GEODE-8670
> URL: https://issues.apache.org/jira/browse/GEODE-8670
> Project: Geode
> Issue Type: Test
> Components: membership, tests
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Since working on GEODE-8609, I found that the regex in ReconnectDUnitTest is
> incorrect. Specifically it looks like this:
> {noformat}
> IgnoredException.addIgnoredException("ForcedDisconnectException||Possible
> loss of quorum");
> {noformat}
> When removing the double pipe ({{||}}) various test methods fail with a
> {{NullPointerException}}. For example:
> {noformat}
> 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-vm1.log' at line 692
> [fatal 2020/10/29 05:59:26.027 PDT
> tid=203] Uncaught exception in thread Thread[Location services restart
> thread,5,RMI Runtime]
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.InternalLocator.attemptReconnect(InternalLocator.java:1108)
> at
> org.apache.geode.distributed.internal.InternalLocator.lambda$launchRestartThread$4(InternalLocator.java:1070)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> There is also an additional {{DistributedSystemDisconnectedException}} which
> probably just requires an addition to the other ignored exceptions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17233358#comment-17233358
]
ASF subversion and git services commented on GEODE-8704:
Commit 8f8cc7b62be9e7d3a20f18e38fe2cff3228a55bb in geode's branch
refs/heads/feature/GEODE-8444 from Sarah
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8f8cc7b ]
GEODE-8704: many CI failures in Jetty9CachingClientServerTest (#5745)
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in
