[jira] [Resolved] (GEODE-8275) Make mass-test-run a first-class pipeline
[ https://issues.apache.org/jira/browse/GEODE-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8275. - Fix Version/s: 1.14.0 Resolution: Fixed > Make mass-test-run a first-class pipeline > - > > Key: GEODE-8275 > URL: https://issues.apache.org/jira/browse/GEODE-8275 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > Automate the run and report-gen of mass-test-run for geode develop. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8289) Gradle clean does not clean geode-old-versions
[ https://issues.apache.org/jira/browse/GEODE-8289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8289. - Fix Version/s: 1.14.0 Resolution: Fixed > Gradle clean does not clean geode-old-versions > -- > > Key: GEODE-8289 > URL: https://issues.apache.org/jira/browse/GEODE-8289 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > Expected behavior: `./gradlew clean` will remove the downloaded and extracted > old versions from my tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8288) Match Redis's glob-style pattern
[ https://issues.apache.org/jira/browse/GEODE-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8288: Fix Version/s: 1.14.0 > Match Redis's glob-style pattern > > > Key: GEODE-8288 > URL: https://issues.apache.org/jira/browse/GEODE-8288 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Major > Fix For: 1.14.0 > > > Redis has their own glob-style pattern ([https://redis.io/commands/keys]). > Change our implementation to match that of Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8285) Serializables Sanctioning Prescribes Wrong Destination Path
[
https://issues.apache.org/jira/browse/GEODE-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8285:
Fix Version/s: 1.14.0
> Serializables Sanctioning Prescribes Wrong Destination Path
> ---
>
> Key: GEODE-8285
> URL: https://issues.apache.org/jira/browse/GEODE-8285
> Project: Geode
> Issue Type: Bug
> Components: tools
>Reporter: Bill Burcham
>Assignee: Louis R. Jacome
>Priority: Major
> Labels: starter
> Fix For: 1.14.0
>
>
> Serializable analysis classes derived from
> {{AnalyzeSerializablesJUnitTestBase}}, intend to inform the developer to copy
> a generated {{excludedClasses.txt}} file over a
> {{sanctionedDataSerializables.txt}} in a _resources_ directory. The paths can
> get long and complicated so it's nice that the analyzers provide the paths,
> ostensibly so that a developer can simply copy them into a {{cp}} line at the
> terminal.
> There is a problem with one of the paths, at least as generated by
> {{AnalyzeCoreSerializablesJUnitTest}}, but also, I suspect in all the classes
> derived from {{AnalyzeSerializablesJUnitTestBase}}. Here is an example of the
> output generated by the former…
> I ran:
> {noformat}
> ± |feature/GEODE-8240-version-ordinal-type → Bill {3} ✓| → ./gradlew
> :geode-core:integrationTest --tests=AnalyzeCoreSerializablesJUnitTest
> {noformat}
> and it output:
> {noformat}
> If the class is not persisted or sent over the wire add it to the file
> /Users/bburcham/Projects/geode/geode-core/build/resources/integrationTest/org/apache/geode/codeAnalysis/excludedClasses.txt
> Otherwise if this doesn't break backward compatibility, copy the file
> /Users/bburcham/Projects/geode/geode-core/build/integrationTest/actualDataSerializables.dat
> to
> /Users/bburcham/Projects/geode/geode-core/build/resources/integrationTest/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt.
> {noformat}
> so ostensibly I should:
> {noformat}
> cp
> /Users/bburcham/Projects/geode/geode-core/build/integrationTest/actualDataSerializables.dat
>
> /Users/bburcham/Projects/geode/geode-core/build/resources/integrationTest/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
> {noformat}
> But in fact the destination is wrong! Notice that it is a {{.../build/...}}
> directory?!?
> What I really needed was:
> {noformat}
> cp
> /Users/bburcham/Projects/geode/geode-core/build/integrationTest/actualDataSerializables.dat
>
> /Users/bburcham/Projects/geode/geode-core/src/integrationTest/resources/org/apache/geode/codeAnalysis/sanctionedDataSerializables.txt
> {noformat}
> The prefix on the second path was:
> {noformat}
> /Users/bburcham/Projects/geode/geode-core/build/resources
> {noformat}
> but needed to be:
> {noformat}
> /Users/bburcham/Projects/geode/geode-core/src/integrationTest/resources
> {noformat}
> h2. Reproduction
> To reproduce this, modify some {{toData}} on some serializable class in the
> {{geode-core}} module e.g. {{RegionVersionVector}}, by adding some innocuous
> code like:
> {code}
> System.out.println("hi!");
> {code}
> And then run:
> {noformat}
> $ ./gradlew :geode-core:integrationTest
> --tests=AnalyzeCoreSerializablesJUnitTest
> {noformat}
> You'll see the an advice block like the one I provided above and you'll see
> the incorrect destination directory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-4564) Remove singleton calls from product code in org.apache.geode.redis.internal.executor.list
[ https://issues.apache.org/jira/browse/GEODE-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-4564: Fix Version/s: (was: 1.13.0) 1.14.0 > Remove singleton calls from product code in > org.apache.geode.redis.internal.executor.list > - > > Key: GEODE-4564 > URL: https://issues.apache.org/jira/browse/GEODE-4564 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Kirk Lund >Priority: Major > Fix For: 1.14.0 > > > These product classes in org.apache.geode.redis.internal.executor.list invoke > singleton getters. > GemFireCacheImpl.getInstance(): > * ListExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-4564) Remove singleton calls from product code in org.apache.geode.redis.internal.executor.list
[ https://issues.apache.org/jira/browse/GEODE-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148226#comment-17148226 ] Darrel Schneider commented on GEODE-4564: - Here is the commit and ticket that removed the redis list code: commit a05b86dc7b847844a99f300bd04132137dfc9597 Author: Darrel Schneider Date: Fri May 22 17:42:53 2020 -0700 GEODE-8175: remove unsupported redis commands (#5146) Removed list and zset commands. Removed redis HyperLog commands. Removed redis transaction commands. > Remove singleton calls from product code in > org.apache.geode.redis.internal.executor.list > - > > Key: GEODE-4564 > URL: https://issues.apache.org/jira/browse/GEODE-4564 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > > These product classes in org.apache.geode.redis.internal.executor.list invoke > singleton getters. > GemFireCacheImpl.getInstance(): > * ListExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-4564) Remove singleton calls from product code in org.apache.geode.redis.internal.executor.list
[ https://issues.apache.org/jira/browse/GEODE-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148223#comment-17148223 ] Darrel Schneider commented on GEODE-4564: - The redis "list" data type implementation was completely removed from our redis impl and that resolved this ticket. > Remove singleton calls from product code in > org.apache.geode.redis.internal.executor.list > - > > Key: GEODE-4564 > URL: https://issues.apache.org/jira/browse/GEODE-4564 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > > These product classes in org.apache.geode.redis.internal.executor.list invoke > singleton getters. > GemFireCacheImpl.getInstance(): > * ListExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148217#comment-17148217
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r447323644
##
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/VersionOrdinal.java
##
@@ -0,0 +1,83 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.internal.serialization;
+
+/**
+ * VersionOrdinal is able to represent not only currently-known
+ * Geode versions but future versions as well. This is necessary
+ * because during rolling upgrades Geode manipulates member
+ * identifiers for members running newer versions of the software.
+ * In that case we receive the ordinal over the network
+ * (serialization) but we don't know other version details such as
+ * major/minor/patch version, which are known to the Version class.
+ *
+ * Implementations must define equals() and hashCode() based on
+ * ordinal() result. And since this interface extends Comparable,
+ * implementations must define compareTo() as well.
+ *
+ * Unlike Version (a subtype of VersionOrdinal which acts like an
+ * enumerated type), VersionOrdinal does not, in general, guarantee
+ * that if vo1.equals(vo2) then vo1 == vo2.
+ *
+ * Use the Versioning factory class to construct objects implementing
+ * this interface. All instances of known versions are defined as
+ * constants in the Version class, e.g. Version.GEODE_1_11_0
+ */
+public interface VersionOrdinal extends Comparable {
Review comment:
Corrected this and went one better: added a new unit test for
`VersionOrdinalImpl`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of
[jira] [Commented] (GEODE-8250) Improve documentation for logging
[ https://issues.apache.org/jira/browse/GEODE-8250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148196#comment-17148196 ] ASF GitHub Bot commented on GEODE-8250: --- kirklund commented on pull request #5309: URL: https://github.com/apache/geode/pull/5309#issuecomment-651417252 :geode-assembly:docker SIGABRT. I think we just need to rerun tests again and hopefully Docker will behave. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve documentation for logging > - > > Key: GEODE-8250 > URL: https://issues.apache.org/jira/browse/GEODE-8250 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, logging > Fix For: 1.14.0 > > > The documentation pages for logging need some fixes, clarification, and > examples. Specifically the docs need updating to cover the newer geode-log4j > module and its custom appenders. Examples should include how to use custom > logging config with optional usage of the latest version of Geode's custom > appenders and pattern converters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148194#comment-17148194 ] ASF GitHub Bot commented on GEODE-8095: --- mhansonp opened a new pull request #5327: URL: https://github.com/apache/geode/pull/5327 …Command (#5300) * GEODE-8095: Changes to make GEODE Respond to Restore Redundancy (cherry picked from commit f5c5e2cc7860c132074a16351ca4db847f64d6f7) Co-authored-by: Jinmei Liao 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 > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.13.0, 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[
https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148192#comment-17148192
]
ASF GitHub Bot commented on GEODE-7670:
---
agingade commented on a change in pull request #4848:
URL: https://github.com/apache/geode/pull/4848#discussion_r447308423
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/PartitionedRegionClearWithConcurrentOperationsDUnitTest.java
##
@@ -0,0 +1,680 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import static org.apache.geode.internal.util.ArrayUtils.asList;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.dunit.VM.getVM;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
+
+import java.io.Serializable;
+import java.time.Instant;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Optional;
+import java.util.stream.IntStream;
+
+import junitparams.JUnitParamsRunner;
+import junitparams.Parameters;
+import junitparams.naming.TestCaseName;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+
+import org.apache.geode.ForcedDisconnectException;
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheWriter;
+import org.apache.geode.cache.CacheWriterException;
+import org.apache.geode.cache.PartitionAttributes;
+import org.apache.geode.cache.PartitionAttributesFactory;
+import org.apache.geode.cache.PartitionedRegionPartialClearException;
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.RegionEvent;
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.cache.util.CacheWriterAdapter;
+import org.apache.geode.distributed.DistributedSystemDisconnectedException;
+import org.apache.geode.distributed.internal.DMStats;
+import org.apache.geode.distributed.internal.InternalDistributedSystem;
+import
org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper;
+import org.apache.geode.test.dunit.AsyncInvocation;
+import org.apache.geode.test.dunit.VM;
+import org.apache.geode.test.dunit.rules.CacheRule;
+import org.apache.geode.test.dunit.rules.DistributedRule;
+
+/**
+ * Tests to verify that {@link PartitionedRegion#clear()} operation can be
executed multiple times
+ * on the same region while other cache operations are being executed
concurrently and members are
+ * added or removed.
+ */
+@RunWith(JUnitParamsRunner.class)
+public class PartitionedRegionClearWithConcurrentOperationsDUnitTest
implements Serializable {
+ private static final Integer BUCKETS = 13;
+ private static final String REGION_NAME = "PartitionedRegion";
+ private static final String TEST_CASE_NAME =
+ "[{index}] {method}(Coordinator:{0}, RegionType:{1})";
+
+ @Rule
+ public DistributedRule distributedRule = new DistributedRule(3);
+
+ @Rule
+ public CacheRule cacheRule = CacheRule.builder().createCacheInAll().build();
+
+ private VM accessor, server1, server2;
+
+ private enum TestVM {
+ACCESSOR(0), SERVER1(1), SERVER2(2);
+
+final int vmNumber;
+
+TestVM(int vmNumber) {
+ this.vmNumber = vmNumber;
+}
+ }
+
+ @SuppressWarnings("unused")
+ static RegionShortcut[] regionTypes() {
+return new RegionShortcut[] {
+RegionShortcut.PARTITION,
+RegionShortcut.PARTITION_REDUNDANT
+};
+ }
+
+ @SuppressWarnings("unused")
+ static TestVM[] vms() {
+return new TestVM[] {
+TestVM.SERVER1, TestVM.ACCESSOR
+};
+ }
+
+ @SuppressWarnings("unused")
+ static Object[] vmAndRegionTypes() {
+ArrayList parameters = new ArrayList<>();
+RegionShortcut[] regionShortcuts = regionTypes();
+
+Arrays.stream(regionShortcuts).forEach(regionShortcut -> {
+ parameters.add(new Object[] {TestVM.SERVER1, regionShortcut});
+ parameters.add(new
[jira] [Created] (GEODE-8321) Change JDK in use to BellSoft's Liberica JDK
Sean Goller created GEODE-8321: -- Summary: Change JDK in use to BellSoft's Liberica JDK Key: GEODE-8321 URL: https://issues.apache.org/jira/browse/GEODE-8321 Project: Geode Issue Type: Improvement Components: ci Reporter: Sean Goller Use BellSoft's Liberica variant of OpenJDK for all testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148178#comment-17148178
]
ASF GitHub Bot commented on GEODE-8240:
---
bschuchardt commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r447282170
##
File path:
geode-serialization/src/main/java/org/apache/geode/internal/serialization/VersionOrdinal.java
##
@@ -0,0 +1,83 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+
+package org.apache.geode.internal.serialization;
+
+/**
+ * VersionOrdinal is able to represent not only currently-known
+ * Geode versions but future versions as well. This is necessary
+ * because during rolling upgrades Geode manipulates member
+ * identifiers for members running newer versions of the software.
+ * In that case we receive the ordinal over the network
+ * (serialization) but we don't know other version details such as
+ * major/minor/patch version, which are known to the Version class.
+ *
+ * Implementations must define equals() and hashCode() based on
+ * ordinal() result. And since this interface extends Comparable,
+ * implementations must define compareTo() as well.
+ *
+ * Unlike Version (a subtype of VersionOrdinal which acts like an
+ * enumerated type), VersionOrdinal does not, in general, guarantee
+ * that if vo1.equals(vo2) then vo1 == vo2.
+ *
+ * Use the Versioning factory class to construct objects implementing
+ * this interface. All instances of known versions are defined as
+ * constants in the Version class, e.g. Version.GEODE_1_11_0
+ */
+public interface VersionOrdinal extends Comparable {
Review comment:
VersionOrdinal's methods should take VersionOrdinal arguments.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect
[jira] [Resolved] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-8110.
--
Fix Version/s: 1.14.0
Resolution: Fixed
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
> Fix For: 1.14.0
>
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148174#comment-17148174
]
ASF subversion and git services commented on GEODE-8110:
Commit 3f3b77e8a519c4d812c0eb008a38ae0c5b1c1a99 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f3b77e ]
GEODE-8110: Ignore AlertingIOException in JMXMBeanReconnectDUnitTest (#5323)
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8060) GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8060:
Fix Version/s: (was: 1.13.0)
1.14.0
> GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes fails
> intermittently
> -
>
> Key: GEODE-8060
> URL: https://issues.apache.org/jira/browse/GEODE-8060
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.GemFireCacheImplCloseTest >
> close_blocksUntilFirstCallToCloseCompletes FAILED
> org.junit.ComparisonFailure: [ThreadId1=47 and threadId2=49]
> expected:<4[7]L> but was:<4[9]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes(GemFireCacheImplCloseTest.java:225)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148173#comment-17148173
]
ASF GitHub Bot commented on GEODE-8110:
---
kirklund merged pull request #5323:
URL: https://github.com/apache/geode/pull/5323
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
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148172#comment-17148172
]
ASF GitHub Bot commented on GEODE-8110:
---
kirklund commented on pull request #5323:
URL: https://github.com/apache/geode/pull/5323#issuecomment-651397701
@mivanac DistributedTestOpenJDK11 hit GEODE-8172 which is unrelated to 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
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8060) GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8060:
Fix Version/s: (was: 1.14.0)
1.13.0
> GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes fails
> intermittently
> -
>
> Key: GEODE-8060
> URL: https://issues.apache.org/jira/browse/GEODE-8060
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.13.0
>
>
> {noformat}
> org.apache.geode.internal.cache.GemFireCacheImplCloseTest >
> close_blocksUntilFirstCallToCloseCompletes FAILED
> org.junit.ComparisonFailure: [ThreadId1=47 and threadId2=49]
> expected:<4[7]L> but was:<4[9]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.GemFireCacheImplCloseTest.close_blocksUntilFirstCallToCloseCompletes(GemFireCacheImplCloseTest.java:225)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7956) Correct documentation of legal region names
[ https://issues.apache.org/jira/browse/GEODE-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7956: Fix Version/s: 1.13.0 > Correct documentation of legal region names > --- > > Key: GEODE-7956 > URL: https://issues.apache.org/jira/browse/GEODE-7956 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Darrel Schneider >Assignee: Mario Kevo >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > According to this: > https://geode.apache.org/docs/guide/111/basic_config/data_regions/region_naming.html > region names can only contain alphanumeric, dash, and underscore. > But the product also supports a dot '.'. > See RegionNameValidation and RegionNameValidationTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8317) WindowsAcceptanceTestOpenJDK8 failure command 'docker'' finished with non-zero exit value 1
[
https://issues.apache.org/jira/browse/GEODE-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Goller resolved GEODE-8317.
Resolution: Fixed
reverting the code that caused this bug.
> WindowsAcceptanceTestOpenJDK8 failure command 'docker'' finished with
> non-zero exit value 1
> ---
>
> Key: GEODE-8317
> URL: https://issues.apache.org/jira/browse/GEODE-8317
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Mark Hanson
>Assignee: Sean Goller
>Priority: Major
>
> {noformat}
> 43:14FAILURE: Build failed with an exception.
> 07:43:14
> 07:43:14* What went wrong:
> 07:43:14Execution failed for task ':geode-assembly:docker'.
> 07:43:14> Process 'command 'docker'' finished with non-zero exit value 1
> 07:43:14
> 07:43:14* Try:
> 07:43:14Run with --stacktrace option to get the stack trace. Run with --info
> or --debug option to get more log output. Run with --scan to get full
> insights.
> 07:43:14
> 07:43:14* Get more help at https://help.gradle.org
> 07:43:14
> 07:43:14BUILD FAILED in 13m 17s
> 07:43:14
> {noformat}
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-results/acceptanceTest/1593441997/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-artifacts/1593441997/windows-acceptancetestfiles-OpenJDK8-1.14.0-build.0191.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8320) SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
[
https://issues.apache.org/jira/browse/GEODE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-8320:
---
Summary:
SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
is failiing (was:
SerialWanStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
is failiing)
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> is failiing
> ---
>
> Key: GEODE-8320
> URL: https://issues.apache.org/jira/browse/GEODE-8320
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> 11:55:01
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
> in VM 2 running on Host 249227cf2774 with 8 VMs
> 11:55:01
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 11:55:01
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses int, intorg.apache.geode.cache.Region Expected region entries:
> 2 but actual entries: 1 present region keyset [7435200, <*
> Intentionally cut out by Jira submitter *> 8851200] expected:<2> but
> was:<1> within 5 minutes.
> 11:55:01
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 11:55:01
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 11:55:01
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> java.lang.AssertionError: Expected region entries: 2 but actual entries:
> 1 present region keyset [7435200, <*Intentionally cut out by Jira
> submitter*> ] expected:<2> but was:<1>
> 12:31:11
> {noformat}
>
>
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8091) AuthenticationRequiredException: Failed to find the authenticated user" at startup when trying to start locator
[ https://issues.apache.org/jira/browse/GEODE-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8091: Fix Version/s: 1.14.0 > AuthenticationRequiredException: Failed to find the authenticated user" at > startup when trying to start locator > --- > > Key: GEODE-8091 > URL: https://issues.apache.org/jira/browse/GEODE-8091 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > when starting up a locator using --dir (the dir would have a cluster_config > directory that would have some jars deployed) and > --load-cluster-configuration-from-dir=true, and the locator has a security > manager, you get the following exception: > gfsh>start locator --name=locator --dir=locator > --load-cluster-configuration-from-dir=true > --properties-file=locator.properties > Starting a Geode Locator in /Users/jiliao/my_geode/tmp/locator.1.10... > The Locator process terminated unexpectedly with exit status 1. Please refer > to the log file in /Users/jiliao/my_geode/tmp/locator.1.10 for full details. > Exception in thread "main" > org.apache.geode.security.AuthenticationRequiredException: Failed to find the > authenticated user. > at > org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:122) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.getDeployedBy(InternalConfigurationPersistenceService.java:853) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.readConfiguration(InternalConfigurationPersistenceService.java:845) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.loadSharedConfigurationFromDir(InternalConfigurationPersistenceService.java:721) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.initSharedConfiguration(InternalConfigurationPersistenceService.java:483) > at > org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1380) > at > org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:779) > at > org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:774) > at > org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:755) > at > org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:386) > at > org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:714) > at > org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:621) > at > org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:215) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8131) alert service hangs, blocking cache operations
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8131:
Fix Version/s: 1.14.0
1.13.0
> alert service hangs, blocking cache operations
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0,
> 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
>Reporter: Bruce J Schuchardt
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. The alerting system should not block other threads. Maybe a
> background thread could consume and transmit alerts to alert-listeners?
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:464)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:448)
> at
>
[jira] [Updated] (GEODE-8251) exception creating domain.Configuration stops locator startup after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8251:
Fix Version/s: 1.14.0
> exception creating domain.Configuration stops locator startup after rolling
> upgrade
> ---
>
> Key: GEODE-8251
> URL: https://issues.apache.org/jira/browse/GEODE-8251
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.13.0, 1.14.0
>
>
> As reported on the dev@geode mailing list
> https://markmail.org/message/qfnnj2s2x7dzbnzx and shown in the
> {{testRollingUpgradeOfGeodeWithGfs}} test in PR:
> https://github.com/apache/geode/pull/5224, if custom Jars are deployed, the
> locator doesn't start after a rolling upgrade and we see:
> {code}
> org.apache.geode.SerializationException: Could not
> create an instance of
> org.apache.geode.management.internal.configuration.domain.Configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7851: Fix Version/s: (was: 1.12.0) 1.12.1 > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Fix For: 1.12.1, 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7779) Concourse BumpXYZ does not include {prerelease}
[
https://issues.apache.org/jira/browse/GEODE-7779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7779:
Fix Version/s: 1.12.1
> Concourse BumpXYZ does not include {prerelease}
> ---
>
> Key: GEODE-7779
> URL: https://issues.apache.org/jira/browse/GEODE-7779
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.12.1, 1.13.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After cutting the 1.13.0 release branch, hitting
> {noformat}BumpMinor{noformat} caused the semver to move from
> {noformat}1.12.0-SNAPSHOT.246{noformat} -> {noformat}1.13.0{noformat}, which
> is then sorted in semantic-order to be higher value than
> {noformat}1.13.0-SNAPSHOT.1{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8091) AuthenticationRequiredException: Failed to find the authenticated user" at startup when trying to start locator
[ https://issues.apache.org/jira/browse/GEODE-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8091: Fix Version/s: 1.12.1 > AuthenticationRequiredException: Failed to find the authenticated user" at > startup when trying to start locator > --- > > Key: GEODE-8091 > URL: https://issues.apache.org/jira/browse/GEODE-8091 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.12.0 >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.12.1, 1.13.0 > > > when starting up a locator using --dir (the dir would have a cluster_config > directory that would have some jars deployed) and > --load-cluster-configuration-from-dir=true, and the locator has a security > manager, you get the following exception: > gfsh>start locator --name=locator --dir=locator > --load-cluster-configuration-from-dir=true > --properties-file=locator.properties > Starting a Geode Locator in /Users/jiliao/my_geode/tmp/locator.1.10... > The Locator process terminated unexpectedly with exit status 1. Please refer > to the log file in /Users/jiliao/my_geode/tmp/locator.1.10 for full details. > Exception in thread "main" > org.apache.geode.security.AuthenticationRequiredException: Failed to find the > authenticated user. > at > org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:122) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.getDeployedBy(InternalConfigurationPersistenceService.java:853) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.readConfiguration(InternalConfigurationPersistenceService.java:845) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.loadSharedConfigurationFromDir(InternalConfigurationPersistenceService.java:721) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.initSharedConfiguration(InternalConfigurationPersistenceService.java:483) > at > org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1380) > at > org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:779) > at > org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:774) > at > org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:755) > at > org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:386) > at > org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:714) > at > org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:621) > at > org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:215) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8131) alert service hangs, blocking cache operations
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8131:
Fix Version/s: (was: 1.12.0)
1.12.1
> alert service hangs, blocking cache operations
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0,
> 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0
>Reporter: Bruce J Schuchardt
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.12.1
>
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. The alerting system should not block other threads. Maybe a
> background thread could consume and transmit alerts to alert-listeners?
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
> at
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:464)
> at
> org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:448)
> at
>
[jira] [Updated] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8029: Fix Version/s: 1.13.0 1.12.1 > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Fix For: 1.12.1, 1.13.0, 1.14.0 > > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:869) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:786) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:716) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:236) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8083) Add API check job to CI
[ https://issues.apache.org/jira/browse/GEODE-8083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8083: Fix Version/s: 1.12.1 > Add API check job to CI > --- > > Key: GEODE-8083 > URL: https://issues.apache.org/jira/browse/GEODE-8083 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > In order to combat API breaking changes, we need a CI job that compares the > current API against the last release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8146) Restore winrm-cli to latest from source
[ https://issues.apache.org/jira/browse/GEODE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8146: Fix Version/s: 1.13.0 1.12.1 > Restore winrm-cli to latest from source > --- > > Key: GEODE-8146 > URL: https://issues.apache.org/jira/browse/GEODE-8146 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Reporter: Robert Houghton >Priority: Major > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > winrm-cli has updated to fix the bug causing GEODE-7788, as reported in > [their github|https://github.com/masterzen/winrm/issues/101] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8287) QueryUtils doNestedIterationsForIndex is not applying an index value correctly and causing the entire region to be iterated
[
https://issues.apache.org/jira/browse/GEODE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8287:
Fix Version/s: 1.12.1
> QueryUtils doNestedIterationsForIndex is not applying an index value
> correctly and causing the entire region to be iterated
> ---
>
> Key: GEODE-8287
> URL: https://issues.apache.org/jira/browse/GEODE-8287
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications
> Fix For: 1.12.1, 1.13.0, 1.14.0
>
>
> Here is an example of the query in 8.2.12:
> {noformat}
> Query Executed in 3.502438E7 ms; indexesUsed(2):mapFieldIndex(Results:
> 500),pkIdIndex(Results: 1) "select vr1, vr2 from /region1 vr1, /region2 vr2
> where vr1.id = vr2.id and vr1.mapField['FIELDNAME']=$1"
> {noformat}
> The number of DistributionStats deserializations is 1,001.
> Here is an example of the query in 9.10.0:
> {noformat}
> Query Executed in 22732.467 ms; rowCount = 500;
> indexesUsed(2):mapFieldIndex(Results: 500),pkIdIndex(Results: 1) "select vr1,
> vr2 from /region1 vr1, /region2 vr2 where vr1.id = vr2.id and
> vr1.mapField['FIELDNAME']=$1"
> {noformat}
> The number of DistributionStats deserializations is 25,001,004
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8095. - Resolution: Fixed > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.13.0, 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8237) Add note about 'alter region' and cluster conf service in doc
[ https://issues.apache.org/jira/browse/GEODE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8237: Fix Version/s: 1.13.0 > Add note about 'alter region' and cluster conf service in doc > - > > Key: GEODE-8237 > URL: https://issues.apache.org/jira/browse/GEODE-8237 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.13.0, 1.14.0 > > > When cluster configuration service is activated and "alter region" command is > applied on a region that was created via cache.xml, the command fails. > This behavior is ok but it is not documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8193) Broken link in statistics list
[ https://issues.apache.org/jira/browse/GEODE-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8193: Fix Version/s: 1.13.0 > Broken link in statistics list > -- > > Key: GEODE-8193 > URL: https://issues.apache.org/jira/browse/GEODE-8193 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.13.0, 1.14.0 > > > The link of region entry heap-based eviction is wrong and shows the html > anchor id in the statistics lists: > * Region Entry Eviction - Heap-based eviction > (HeapLRUStatistics)#section_3B74F6FA08A374FBD92AA23047929B4F) > [https://geode.apache.org/docs/guide/112/reference/statistics_list.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8304) Better highlight steps for building documentation
[ https://issues.apache.org/jira/browse/GEODE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8304. - Resolution: Fixed > Better highlight steps for building documentation > - > > Key: GEODE-8304 > URL: https://issues.apache.org/jira/browse/GEODE-8304 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alexander Murmann >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > While the instructions at > [/dev-tools/docker/docs/README.md|https://github.com/apache/geode/blob/develop/dev-tools/docker/docs/README.md] > are quite simple, the background info above the actual building steps have > lead some users down the path of assuming that they have to first build > bookbinder themselves. It should be clearer that the user simply needs to > follow the build steps and doesn't need Bookbinder on their local machine.. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7796) CI: org.apache.geode.distributed.LocatorDUnitTest testCrashLocatorMultipleTimes hung
[ https://issues.apache.org/jira/browse/GEODE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7796: Fix Version/s: (was: 1.12.0) 1.13.0 > CI: org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes hung > > > Key: GEODE-7796 > URL: https://issues.apache.org/jira/browse/GEODE-7796 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jinmei Liao >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1563 > in the artifacts callbacks/dunit-hang.txt, > Started @ 2020-02-11 00:30:32.499 + > 2020-02-11 01:07:59.054 + org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes > Ended @ 2020-02-11 02:05:31.891 + > and the stacktraces shows thread gets blocked for a long time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7763:
Fix Version/s: 1.13.0
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Assignee: Ernest Burghardt
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0, 1.13.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns
[jira] [Updated] (GEODE-7740) Refactor and combine create_instances.sh for all Geode projects
[ https://issues.apache.org/jira/browse/GEODE-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7740: Fix Version/s: (was: 1.12.0) 1.13.0 > Refactor and combine create_instances.sh for all Geode projects > --- > > Key: GEODE-7740 > URL: https://issues.apache.org/jira/browse/GEODE-7740 > Project: Geode > Issue Type: Improvement > Components: build, ci >Reporter: Robert Houghton >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode and geode-native-client both maintain their own GCE instance creation > scripts for Concourse CI. Combining them will lead to fewer issues as the GCE > APIs move forward, and lighten the load on maintainers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8317) WindowsAcceptanceTestOpenJDK8 failure command 'docker'' finished with non-zero exit value 1
[
https://issues.apache.org/jira/browse/GEODE-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-8317:
--
Assignee: Sean Goller
> WindowsAcceptanceTestOpenJDK8 failure command 'docker'' finished with
> non-zero exit value 1
> ---
>
> Key: GEODE-8317
> URL: https://issues.apache.org/jira/browse/GEODE-8317
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Mark Hanson
>Assignee: Sean Goller
>Priority: Major
>
> {noformat}
> 43:14FAILURE: Build failed with an exception.
> 07:43:14
> 07:43:14* What went wrong:
> 07:43:14Execution failed for task ':geode-assembly:docker'.
> 07:43:14> Process 'command 'docker'' finished with non-zero exit value 1
> 07:43:14
> 07:43:14* Try:
> 07:43:14Run with --stacktrace option to get the stack trace. Run with --info
> or --debug option to get more log output. Run with --scan to get full
> insights.
> 07:43:14
> 07:43:14* Get more help at https://help.gradle.org
> 07:43:14
> 07:43:14BUILD FAILED in 13m 17s
> 07:43:14
> {noformat}
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-results/acceptanceTest/1593441997/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-artifacts/1593441997/windows-acceptancetestfiles-OpenJDK8-1.14.0-build.0191.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8320) SerialWanStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
Mark Hanson created GEODE-8320:
--
Summary:
SerialWanStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
is failiing
Key: GEODE-8320
URL: https://issues.apache.org/jira/browse/GEODE-8320
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Mark Hanson
Fix For: 1.14.0
{noformat}
org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
11:55:01
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
in VM 2 running on Host 249227cf2774 with 8 VMs
11:55:01
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
11:55:01
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
11:55:01
at
org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
11:55:01
11:55:01
Caused by:
11:55:01
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase that
uses int, intorg.apache.geode.cache.Region Expected region entries: 2 but
actual entries: 1 present region keyset [7435200, <* Intentionally cut out
by Jira submitter *> 8851200] expected:<2> but was:<1> within 5 minutes.
11:55:01
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
11:55:01
at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
11:55:01
at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
11:55:01
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
11:55:01
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
11:55:01
at
org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
11:55:01
at
org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
11:55:01
11:55:01
Caused by:
11:55:01
java.lang.AssertionError: Expected region entries: 2 but actual entries:
1 present region keyset [7435200, <*Intentionally cut out by Jira
submitter*> ] expected:<2> but was:<1>
12:31:11
{noformat}
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8320) SerialWanStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
[
https://issues.apache.org/jira/browse/GEODE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-8320:
--
Assignee: Alberto Gomez
> SerialWanStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> is failiing
> ---
>
> Key: GEODE-8320
> URL: https://issues.apache.org/jira/browse/GEODE-8320
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> 11:55:01
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
> in VM 2 running on Host 249227cf2774 with 8 VMs
> 11:55:01
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 11:55:01
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses int, intorg.apache.geode.cache.Region Expected region entries:
> 2 but actual entries: 1 present region keyset [7435200, <*
> Intentionally cut out by Jira submitter *> 8851200] expected:<2> but
> was:<1> within 5 minutes.
> 11:55:01
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 11:55:01
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 11:55:01
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> java.lang.AssertionError: Expected region entries: 2 but actual entries:
> 1 present region keyset [7435200, <*Intentionally cut out by Jira
> submitter*> ] expected:<2> but was:<1>
> 12:31:11
> {noformat}
>
>
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8304) Better highlight steps for building documentation
[ https://issues.apache.org/jira/browse/GEODE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-8304: - Fix Version/s: 1.14.0 1.13.0 > Better highlight steps for building documentation > - > > Key: GEODE-8304 > URL: https://issues.apache.org/jira/browse/GEODE-8304 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alexander Murmann >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > While the instructions at > [/dev-tools/docker/docs/README.md|https://github.com/apache/geode/blob/develop/dev-tools/docker/docs/README.md] > are quite simple, the background info above the actual building steps have > lead some users down the path of assuming that they have to first build > bookbinder themselves. It should be clearer that the user simply needs to > follow the build steps and doesn't need Bookbinder on their local machine.. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7600) DistributedAckRegionCCEDUnitTest and DistributedAckPersistentRegionCCEOffHeapDUnitTest fail in testConcurrentEventsOnEmptyRegion
[ https://issues.apache.org/jira/browse/GEODE-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7600: Fix Version/s: (was: 1.12.0) 1.13.0 > DistributedAckRegionCCEDUnitTest and > DistributedAckPersistentRegionCCEOffHeapDUnitTest fail in > testConcurrentEventsOnEmptyRegion > > > Key: GEODE-7600 > URL: https://issues.apache.org/jira/browse/GEODE-7600 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Mark Hanson >Assignee: Ernest Burghardt >Priority: Major > Labels: GeodeCommons > Fix For: 1.13.0 > > Time Spent: 5h 40m > Remaining Estimate: 0h > > DistributedAckRegionCCEDUnitTest > https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2176 > DistributedAckPersistentRegionCCEOffHeapDUnitTest > https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2143 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7210) RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU fails intermittently with CacheClientProxy was not fulfilled
[
https://issues.apache.org/jira/browse/GEODE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7210:
Fix Version/s: (was: 1.12.0)
1.13.0
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU
> fails intermittently with CacheClientProxy was not fulfilled
> -
>
> Key: GEODE-7210
> URL: https://issues.apache.org/jira/browse/GEODE-7210
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.11.0
>Reporter: Darrel Schneider
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It failed in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1098
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest$$Lambda$180/1742098249.run
> in VM 2 running on Host 672aa6424308 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByCCU(RedundancyLevelPart1DUnitTest.java:237)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelTestBase that
> uses org.apache.geode.internal.cache.tier.sockets.CacheClientProxy was not
> fulfilled within 300 seconds.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8319) NPE due to locator missing cluster config folder
[ https://issues.apache.org/jira/browse/GEODE-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148141#comment-17148141 ] ASF GitHub Bot commented on GEODE-8319: --- jinmeiliao opened a new pull request #5325: URL: https://github.com/apache/geode/pull/5325 …in the working dir 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 > NPE due to locator missing cluster config folder > > > Key: GEODE-8319 > URL: https://issues.apache.org/jira/browse/GEODE-8319 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jinmei Liao >Priority: Major > > Opening a JIRA because I believe any NPE is unacceptable in the product. > Please provide some better more explanatory type of error exception if > missing the cluster configuration in the locator. > Exception in thread "main" java.lang.NullPointerException > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.loadSharedConfigurationFromDir(InternalConfigurationPersistenceService.java:672) > at > org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.initSharedConfiguration(InternalConfigurationPersistenceService.java:435) > at > org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1348) > at > org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:733) > at > org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:729) > at > org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:708) > at > org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:374) > at > org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:679) > at > com.citi.cate.gemfire.CitiGemFireLocatorStart.run(CitiGemFireLocatorStart.java:47) > at > com.citi.cate.gemfire.CitiGemFireLocatorStart.main(CitiGemFireLocatorStart.java:115) > Environment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8319) NPE due to locator missing cluster config folder
Jinmei Liao created GEODE-8319: -- Summary: NPE due to locator missing cluster config folder Key: GEODE-8319 URL: https://issues.apache.org/jira/browse/GEODE-8319 Project: Geode Issue Type: Bug Components: management Reporter: Jinmei Liao Opening a JIRA because I believe any NPE is unacceptable in the product. Please provide some better more explanatory type of error exception if missing the cluster configuration in the locator. Exception in thread "main" java.lang.NullPointerException at org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.loadSharedConfigurationFromDir(InternalConfigurationPersistenceService.java:672) at org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.initSharedConfiguration(InternalConfigurationPersistenceService.java:435) at org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1348) at org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:733) at org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:729) at org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:708) at org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:374) at org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:679) at com.citi.cate.gemfire.CitiGemFireLocatorStart.run(CitiGemFireLocatorStart.java:47) at com.citi.cate.gemfire.CitiGemFireLocatorStart.main(CitiGemFireLocatorStart.java:115) Environment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson resolved GEODE-8272. Resolution: Fixed The necessary changes have been made to enable the REST command for Restore Redundancy by generalizing the implementation of GFSH REST implementation. > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148137#comment-17148137 ] Mark Hanson commented on GEODE-8272: Added changes necessary to support REST version of the command. > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-8272: --- Fix Version/s: 1.14.0 > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Fix For: 1.13.0, 1.14.0 > > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8272) Refactor GFSH Restore Redundancy Command code to allow for REST API
[ https://issues.apache.org/jira/browse/GEODE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-8272: --- Fix Version/s: 1.13.0 > Refactor GFSH Restore Redundancy Command code to allow for REST API > --- > > Key: GEODE-8272 > URL: https://issues.apache.org/jira/browse/GEODE-8272 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Fix For: 1.13.0 > > > Refactor GFSH Restore Redundancy Command code to allow for REST API > > The core code path is specific to GFSH right now and needs a few changes to > support the REST API command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-8095: --- Fix Version/s: 1.13.0 > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.13.0, 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7982) Suspect string from RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
[
https://issues.apache.org/jira/browse/GEODE-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148132#comment-17148132
]
Bill Burcham commented on GEODE-7982:
-
I un-assigned [~upthewaterspout] since he's not working on this.
> Suspect string from
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> ---
>
> Key: GEODE-7982
> URL: https://issues.apache.org/jira/browse/GEODE-7982
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Dan Smith
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This upgrade test failed with a suspect string from a background thread:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/49#A
> {noformat}
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.9.1, with reindex=false, singleHopEnabled=true] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 8954
> /home/geode/.gradle/caches/modules-2/file[info 2020/04/13 18:04:58.681
> GMT tid=81] Communication with locator
> /172.17.0.40:23082 failed with java.io.EOFException: Locator at
> /172.17.0.40:23082 did not respond. This is normal if the locator was
> shutdown. If it wasn't check its log for exceptions..
> java.io.EOFException: Locator at /172.17.0.40:23082 did not respond. This
> is normal if the locator was shutdown. If it wasn't check its log for
> exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7982) Suspect string from RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
[
https://issues.apache.org/jira/browse/GEODE-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-7982:
---
Assignee: (was: Dan Smith)
> Suspect string from
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> ---
>
> Key: GEODE-7982
> URL: https://issues.apache.org/jira/browse/GEODE-7982
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Dan Smith
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This upgrade test failed with a suspect string from a background thread:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/49#A
> {noformat}
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.9.1, with reindex=false, singleHopEnabled=true] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 8954
> /home/geode/.gradle/caches/modules-2/file[info 2020/04/13 18:04:58.681
> GMT tid=81] Communication with locator
> /172.17.0.40:23082 failed with java.io.EOFException: Locator at
> /172.17.0.40:23082 did not respond. This is normal if the locator was
> shutdown. If it wasn't check its log for exceptions..
> java.io.EOFException: Locator at /172.17.0.40:23082 did not respond. This
> is normal if the locator was shutdown. If it wasn't check its log for
> exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7982) Suspect string from RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
[
https://issues.apache.org/jira/browse/GEODE-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7982:
Fix Version/s: (was: 1.13.0)
> Suspect string from
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> ---
>
> Key: GEODE-7982
> URL: https://issues.apache.org/jira/browse/GEODE-7982
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This upgrade test failed with a suspect string from a background thread:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/49#A
> {noformat}
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.9.1, with reindex=false, singleHopEnabled=true] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 8954
> /home/geode/.gradle/caches/modules-2/file[info 2020/04/13 18:04:58.681
> GMT tid=81] Communication with locator
> /172.17.0.40:23082 failed with java.io.EOFException: Locator at
> /172.17.0.40:23082 did not respond. This is normal if the locator was
> shutdown. If it wasn't check its log for exceptions..
> java.io.EOFException: Locator at /172.17.0.40:23082 did not respond. This
> is normal if the locator was shutdown. If it wasn't check its log for
> exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8313) Improve RedisData synchronization for toData
[
https://issues.apache.org/jira/browse/GEODE-8313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148112#comment-17148112
]
ASF GitHub Bot commented on GEODE-8313:
---
lgtm-com[bot] commented on pull request #5318:
URL: https://github.com/apache/geode/pull/5318#issuecomment-651330036
This pull request **introduces 2 alerts** when merging
822952c8a258260b9cf6e5f533e427abaaddbcf0 into
4caa90beffe3321548b3364951287a6d9db314e5 - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-e4f02bcdca710759856a916106376dc10927b95c)
**new alerts:**
* 2 for Non\-synchronized override of synchronized method
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Improve RedisData synchronization for toData
>
>
> Key: GEODE-8313
> URL: https://issues.apache.org/jira/browse/GEODE-8313
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> During GII, redis data structures may throw
> {{ConcurrentModificationException}}s from {{toData}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148090#comment-17148090
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r446354173
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
##
@@ -549,7 +550,7 @@ public void setVersionObjectForTest(Version v) {
}
@Override
- public Version getVersionObject() {
+ public VersionOrdinal getVersionObject() {
Review comment:
Since `IDM` isa `MemberIdentifier` this (overridden) method has to
return a `VersionOrdinal` not a `Version` since, in general, a
`MemberIdentifier` can be for a member that is running an unknown software
version.
I'm renaming `MemberIdentifier.getVersionObject()` =>
`MemberIdentifier.getVersionOrdinalObject()`.
To summarize the state of `IDM` version methods this is what it looks like
now:
```java
// inherited from MemberIdentifier. It has a new name to make the return
type explicit
@Override
public VersionOrdinal getVersionOrdinalObject() {…}
/**
* If this member runs a version known in this JVM then return that
Version.
* If this member does not run a known version then return Version.CURRENT.
*
* In various serialization scenarios we want the well-known version for
this
* member, or, if it doesn't have a well-known version, we want the current
* (in this JVM) software version. Rather than have that logic spread
around in
* the serialization code, it is centralized here.
*/
public Version getVersionObject() {…}
```
We still have lots of ways to get a `Version` from a `short` version
ordinal. `Version` class has these static methods:
* `fromOrdinal(short ordinal) throws
UnsupportedSerializationVersionException`
* `fromOrdinalOrCurrent(short ordinal)`
* `fromOrdinalNoThrow(short ordinal, boolean returnNullForCurrent)`
There is some unfortunate duplication in those methods. Consolidating that
logic is beyond the scope of 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
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148076#comment-17148076
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r447181500
##
File path:
geode-core/src/upgradeTest/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
##
@@ -191,20 +207,26 @@ void doTestRollAll(String regionType, String objectType,
String startingVersion)
}
putAndVerify(objectType, server1, regionName, 0, 10, server2);
- locator = rollLocatorToCurrent(locator, hostName, locatorPorts[0],
getTestMethodName(),
- locatorString);
+ locator =
+ rollLocatorToCurrent(locator, hostName, locatorPort, locatorProps,
getTestMethodName(),
+ locatorString);
server1 = rollServerToCurrentAndCreateRegion(server1, regionType,
testingDirs[0],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, new int[] {locatorPort});
verifyValues(objectType, regionName, 0, 10, server1);
putAndVerify(objectType, server1, regionName, 5, 15, server2);
putAndVerify(objectType, server2, regionName, 10, 20, server1);
server2 = rollServerToCurrentAndCreateRegion(server2, regionType,
testingDirs[1],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, ports);
verifyValues(objectType, regionName, 0, 10, server2);
putAndVerify(objectType, server2, regionName, 15, 25, server1);
+ String shutDownCommand = "shutdown --include-locators=true";
Review comment:
My latest commit eliminates `gfsh` entirely so the issue with
`shutDownCommand` is moot.
I eliminated use of `gfsh` because I found the test had become flaky on
versions 1.3.0-1.8.0, at least on macOS. On Linux (CI) I did not see the
flakiness. But rather than figuring that out, I decided to grab the view more
directly: by accessing `InternalDistributedSystem` in the locator JVM.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8318) Shutdown hang and abort
Matthew Reddington created GEODE-8318: - Summary: Shutdown hang and abort Key: GEODE-8318 URL: https://issues.apache.org/jira/browse/GEODE-8318 Project: Geode Issue Type: Bug Components: native client Reporter: Matthew Reddington Switching from Ace to Boost.Asio has revealed threading issues related to shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8312) Improve redis pub/sub capabilities
[ https://issues.apache.org/jira/browse/GEODE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148058#comment-17148058 ] ASF subversion and git services commented on GEODE-8312: Commit 4caa90beffe3321548b3364951287a6d9db314e5 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4caa90b ] GEODE-8312: Improve Redis pub/sub capabilities (#5316) * Improve pub/sub implementation * Keep regular subscribed channel names as byte[]'s Co-authored-by: Darrel Schneider > Improve redis pub/sub capabilities > -- > > Key: GEODE-8312 > URL: https://issues.apache.org/jira/browse/GEODE-8312 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > * Add ability to [P]UNSUBSCRIBE from multiple channels. > * Match Redis semantics when subscribing to empty channel name. > * Interact with plain channel names as byte[]s instead of Strings (fixes > issues on Windows). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8312) Improve redis pub/sub capabilities
[ https://issues.apache.org/jira/browse/GEODE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8312. - Fix Version/s: 1.14.0 Resolution: Fixed > Improve redis pub/sub capabilities > -- > > Key: GEODE-8312 > URL: https://issues.apache.org/jira/browse/GEODE-8312 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.14.0 > > > * Add ability to [P]UNSUBSCRIBE from multiple channels. > * Match Redis semantics when subscribing to empty channel name. > * Interact with plain channel names as byte[]s instead of Strings (fixes > issues on Windows). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8312) Improve redis pub/sub capabilities
[ https://issues.apache.org/jira/browse/GEODE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148057#comment-17148057 ] ASF GitHub Bot commented on GEODE-8312: --- dschneider-pivotal merged pull request #5316: URL: https://github.com/apache/geode/pull/5316 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve redis pub/sub capabilities > -- > > Key: GEODE-8312 > URL: https://issues.apache.org/jira/browse/GEODE-8312 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > * Add ability to [P]UNSUBSCRIBE from multiple channels. > * Match Redis semantics when subscribing to empty channel name. > * Interact with plain channel names as byte[]s instead of Strings (fixes > issues on Windows). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8317) WindowsAcceptanceTestOpenJDK8 failure command 'docker'' finished with non-zero exit value 1
Mark Hanson created GEODE-8317:
--
Summary: WindowsAcceptanceTestOpenJDK8 failure command 'docker''
finished with non-zero exit value 1
Key: GEODE-8317
URL: https://issues.apache.org/jira/browse/GEODE-8317
Project: Geode
Issue Type: Bug
Components: ci
Reporter: Mark Hanson
{noformat}
43:14FAILURE: Build failed with an exception.
07:43:14
07:43:14* What went wrong:
07:43:14Execution failed for task ':geode-assembly:docker'.
07:43:14> Process 'command 'docker'' finished with non-zero exit value 1
07:43:14
07:43:14* Try:
07:43:14Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output. Run with --scan to get full insights.
07:43:14
07:43:14* Get more help at https://help.gradle.org
07:43:14
07:43:14BUILD FAILED in 13m 17s
07:43:14
{noformat}
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-results/acceptanceTest/1593441997/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-artifacts/1593441997/windows-acceptancetestfiles-OpenJDK8-1.14.0-build.0191.tgz
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8316) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
Mark Hanson created GEODE-8316:
--
Summary: RollingUpgradeWithGfshDUnitTest >
testRollingUpgradeWithDeployment[] FAILED
Key: GEODE-8316
URL: https://issues.apache.org/jira/browse/GEODE-8316
Project: Geode
Issue Type: Bug
Components: core
Reporter: Mark Hanson
{noformat}
07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> testRollingUpgradeWithDeployment[1.10.0] FAILED
07:26:08java.lang.AssertionError:
07:26:08Expecting file:
07:26:08
07:26:08to exist.
07:26:08
07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> testRollingUpgradeWithDeployment[1.11.0] FAILED
07:26:08java.lang.AssertionError:
07:26:08Expecting file:
07:26:08
07:26:08to exist.
07:26:08
07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> testRollingUpgradeWithDeployment[1.12.0] FAILED
07:26:08java.lang.AssertionError:
07:26:08Expecting file:
07:26:08
07:26:08to exist.
07:26:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8316) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
[
https://issues.apache.org/jira/browse/GEODE-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148051#comment-17148051
]
Mark Hanson commented on GEODE-8316:
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-results/upgradeTest/1593443758/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0191/test-artifacts/1593443758/upgradetestfiles-OpenJDK8-1.14.0-build.0191.tgz
{noformat}
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
> ---
>
> Key: GEODE-8316
> URL: https://issues.apache.org/jira/browse/GEODE-8316
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
>
> {noformat}
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.10.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.11.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.12.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8193) Broken link in statistics list
[ https://issues.apache.org/jira/browse/GEODE-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148044#comment-17148044 ] ASF subversion and git services commented on GEODE-8193: Commit c503f3c2d109a8982193343f38a066a92f82f5b0 in geode's branch refs/heads/support/1.13 from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c503f3c ] GEODE-8193: Broken link in statistics list (#5166) > Broken link in statistics list > -- > > Key: GEODE-8193 > URL: https://issues.apache.org/jira/browse/GEODE-8193 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The link of region entry heap-based eviction is wrong and shows the html > anchor id in the statistics lists: > * Region Entry Eviction - Heap-based eviction > (HeapLRUStatistics)#section_3B74F6FA08A374FBD92AA23047929B4F) > [https://geode.apache.org/docs/guide/112/reference/statistics_list.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8237) Add note about 'alter region' and cluster conf service in doc
[ https://issues.apache.org/jira/browse/GEODE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148047#comment-17148047 ] ASF subversion and git services commented on GEODE-8237: Commit 60003f5d0ae42f73f983016e51918f2751c3a128 in geode's branch refs/heads/support/1.13 from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=60003f5 ] GEODE-8237: Add note about 'alter region' & cluster conf service (#5231) > Add note about 'alter region' and cluster conf service in doc > - > > Key: GEODE-8237 > URL: https://issues.apache.org/jira/browse/GEODE-8237 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When cluster configuration service is activated and "alter region" command is > applied on a region that was created via cache.xml, the command fails. > This behavior is ok but it is not documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8304) Better highlight steps for building documentation
[ https://issues.apache.org/jira/browse/GEODE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148046#comment-17148046 ] ASF subversion and git services commented on GEODE-8304: Commit edabbe3692c2ec84d68f3a3a649a143a4067cd51 in geode's branch refs/heads/support/1.13 from Alexander Murmann [ https://gitbox.apache.org/repos/asf?p=geode.git;h=edabbe3 ] GEODE-8304 - Better highlight steps for building documentation (#5308) Make it clearer that neither a local Bookbinder nor Ruby interpreter is needed to build our documentation book. > Better highlight steps for building documentation > - > > Key: GEODE-8304 > URL: https://issues.apache.org/jira/browse/GEODE-8304 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alexander Murmann >Priority: Major > > While the instructions at > [/dev-tools/docker/docs/README.md|https://github.com/apache/geode/blob/develop/dev-tools/docker/docs/README.md] > are quite simple, the background info above the actual building steps have > lead some users down the path of assuming that they have to first build > bookbinder themselves. It should be clearer that the user simply needs to > follow the build steps and doesn't need Bookbinder on their local machine.. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7956) Correct documentation of legal region names
[ https://issues.apache.org/jira/browse/GEODE-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148045#comment-17148045 ] ASF subversion and git services commented on GEODE-7956: Commit f3fb1830e2d4e13cf9ffd8126783b3aa82871f18 in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3fb183 ] GEODE-7956: Correct documentation of legal region names, add dot as a legal character > Correct documentation of legal region names > --- > > Key: GEODE-7956 > URL: https://issues.apache.org/jira/browse/GEODE-7956 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Darrel Schneider >Assignee: Mario Kevo >Priority: Major > Fix For: 1.14.0 > > > According to this: > https://geode.apache.org/docs/guide/111/basic_config/data_regions/region_naming.html > region names can only contain alphanumeric, dash, and underscore. > But the product also supports a dot '.'. > See RegionNameValidation and RegionNameValidationTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7956) Correct documentation of legal region names
[ https://issues.apache.org/jira/browse/GEODE-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148040#comment-17148040 ] ASF subversion and git services commented on GEODE-7956: Commit f3fb1830e2d4e13cf9ffd8126783b3aa82871f18 in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3fb183 ] GEODE-7956: Correct documentation of legal region names, add dot as a legal character > Correct documentation of legal region names > --- > > Key: GEODE-7956 > URL: https://issues.apache.org/jira/browse/GEODE-7956 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Darrel Schneider >Assignee: Mario Kevo >Priority: Major > Fix For: 1.14.0 > > > According to this: > https://geode.apache.org/docs/guide/111/basic_config/data_regions/region_naming.html > region names can only contain alphanumeric, dash, and underscore. > But the product also supports a dot '.'. > See RegionNameValidation and RegionNameValidationTest -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8193) Broken link in statistics list
[ https://issues.apache.org/jira/browse/GEODE-8193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148039#comment-17148039 ] ASF subversion and git services commented on GEODE-8193: Commit c503f3c2d109a8982193343f38a066a92f82f5b0 in geode's branch refs/heads/support/1.13 from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c503f3c ] GEODE-8193: Broken link in statistics list (#5166) > Broken link in statistics list > -- > > Key: GEODE-8193 > URL: https://issues.apache.org/jira/browse/GEODE-8193 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The link of region entry heap-based eviction is wrong and shows the html > anchor id in the statistics lists: > * Region Entry Eviction - Heap-based eviction > (HeapLRUStatistics)#section_3B74F6FA08A374FBD92AA23047929B4F) > [https://geode.apache.org/docs/guide/112/reference/statistics_list.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8304) Better highlight steps for building documentation
[ https://issues.apache.org/jira/browse/GEODE-8304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148041#comment-17148041 ] ASF subversion and git services commented on GEODE-8304: Commit edabbe3692c2ec84d68f3a3a649a143a4067cd51 in geode's branch refs/heads/support/1.13 from Alexander Murmann [ https://gitbox.apache.org/repos/asf?p=geode.git;h=edabbe3 ] GEODE-8304 - Better highlight steps for building documentation (#5308) Make it clearer that neither a local Bookbinder nor Ruby interpreter is needed to build our documentation book. > Better highlight steps for building documentation > - > > Key: GEODE-8304 > URL: https://issues.apache.org/jira/browse/GEODE-8304 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alexander Murmann >Priority: Major > > While the instructions at > [/dev-tools/docker/docs/README.md|https://github.com/apache/geode/blob/develop/dev-tools/docker/docs/README.md] > are quite simple, the background info above the actual building steps have > lead some users down the path of assuming that they have to first build > bookbinder themselves. It should be clearer that the user simply needs to > follow the build steps and doesn't need Bookbinder on their local machine.. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8237) Add note about 'alter region' and cluster conf service in doc
[ https://issues.apache.org/jira/browse/GEODE-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148042#comment-17148042 ] ASF subversion and git services commented on GEODE-8237: Commit 60003f5d0ae42f73f983016e51918f2751c3a128 in geode's branch refs/heads/support/1.13 from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=60003f5 ] GEODE-8237: Add note about 'alter region' & cluster conf service (#5231) > Add note about 'alter region' and cluster conf service in doc > - > > Key: GEODE-8237 > URL: https://issues.apache.org/jira/browse/GEODE-8237 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When cluster configuration service is activated and "alter region" command is > applied on a region that was created via cache.xml, the command fails. > This behavior is ok but it is not documented. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6622) WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover[from_v160] FAILED
[
https://issues.apache.org/jira/browse/GEODE-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147997#comment-17147997
]
Mark Hanson commented on GEODE-6622:
Failed again...
{noformat}
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover
>
testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover[from_v1.11.0]
FAILED
18:33:01org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover$$Lambda$64/1544169074.run
in VM 4 running on Host 29c3de3ca925 with 8 VMs
18:33:01at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
18:33:01at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
18:33:01at
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.java:73)
18:33:01
18:33:01Caused by:
18:33:01java.net.BindException: Failed to create server socket on
172.17.0.28[20345]
18:33:01at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
18:33:01at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:56)
18:33:01at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:48)
18:33:01at
org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:203)
18:33:01at
org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:193)
18:33:01at
org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:188)
18:33:01at
org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:108)
18:33:01at
org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:638)
18:33:01at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:383)
18:33:01at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:338)
18:33:01at
org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
18:33:01at
org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
18:33:01at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:105)
18:33:01at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:97)
18:33:01at
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.lambda$testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover$67afc7f8$1(WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.java:73)
18:33:01
18:33:01Caused by:
18:33:01java.net.BindException: Address already in use (Bind failed)
18:33:01at java.net.PlainSocketImpl.socketBind(Native Method)
18:33:01at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
18:33:01at java.net.ServerSocket.bind(ServerSocket.java:390)
18:33:01at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:72)
18:33:01... 14 more {noformat}
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0189/test-results/upgradeTest/1593224066/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0189/test-artifacts/1593224066/upgradetestfiles-OpenJDK8-1.14.0-build.0189.tgz
{noformat}
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover.testSecondaryEventsNotReprocessedAfterCurrentSiteMemberFailover[from_v160]
> FAILED
> --
>
> Key: GEODE-6622
> URL: https://issues.apache.org/jira/browse/GEODE-6622
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
>
> Rolling upgrade test
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147981#comment-17147981 ] ASF subversion and git services commented on GEODE-8095: Commit f5c5e2cc7860c132074a16351ca4db847f64d6f7 in geode's branch refs/heads/develop from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f5c5e2c ] GEODE-8095: Changes to make GEODE Respond to Restore Redundancy REST Command (#5300) * GEODE-8095: Changes to make GEODE Respond to Restore Redundancy Co-authored-by: Jinmei Liao > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147982#comment-17147982 ] ASF subversion and git services commented on GEODE-8095: Commit f5c5e2cc7860c132074a16351ca4db847f64d6f7 in geode's branch refs/heads/develop from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f5c5e2c ] GEODE-8095: Changes to make GEODE Respond to Restore Redundancy REST Command (#5300) * GEODE-8095: Changes to make GEODE Respond to Restore Redundancy Co-authored-by: Jinmei Liao > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147979#comment-17147979 ] ASF GitHub Bot commented on GEODE-8095: --- mhansonp merged pull request #5300: URL: https://github.com/apache/geode/pull/5300 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 > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[
https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147973#comment-17147973
]
ASF GitHub Bot commented on GEODE-8095:
---
mhansonp commented on a change in pull request #5300:
URL: https://github.com/apache/geode/pull/5300#discussion_r447120919
##
File path:
geode-web-management/src/main/java/org/apache/geode/management/internal/rest/controllers/RestoreRedundancyOperationController.java
##
@@ -0,0 +1,74 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.rest.controllers;
+
+import static org.apache.geode.management.configuration.Links.URI_VERSION;
+import static
org.apache.geode.management.operation.RestoreRedundancyRequest.RESTORE_REDUNDANCY_ENDPOINT;
+
+import java.util.Optional;
+
+import io.swagger.annotations.ApiOperation;
+import org.springframework.http.HttpStatus;
+import org.springframework.http.ResponseEntity;
+import org.springframework.security.access.prepost.PreAuthorize;
+import org.springframework.web.bind.annotation.GetMapping;
+import org.springframework.web.bind.annotation.PathVariable;
+import org.springframework.web.bind.annotation.PostMapping;
+import org.springframework.web.bind.annotation.RequestBody;
+import org.springframework.web.bind.annotation.RequestMapping;
+import org.springframework.web.bind.annotation.RestController;
+
+import org.apache.geode.internal.security.SecurityService;
+import org.apache.geode.management.api.ClusterManagementListOperationsResult;
+import org.apache.geode.management.api.ClusterManagementOperationResult;
+import org.apache.geode.management.operation.RestoreRedundancyRequest;
+import org.apache.geode.management.runtime.RestoreRedundancyResults;
+
+@RestController("restoreRedundancyOperation")
+@RequestMapping(URI_VERSION)
+public class RestoreRedundancyOperationController extends
AbstractManagementController {
+ @ApiOperation(value = "start restore-redundancy")
+ @PreAuthorize("@securityService.authorize('DATA', 'MANAGE')")
+ @PostMapping(RESTORE_REDUNDANCY_ENDPOINT)
+ public
ResponseEntity> startRestoreRedundancy(
+ @RequestBody RestoreRedundancyRequest operation) {
+operation.setOperator(
+
Optional.ofNullable(securityService).map(SecurityService::getSubject).map(Object::toString)
+.orElse(null));
+ClusterManagementOperationResult result =
+clusterManagementService
+.start(operation);
+return new ResponseEntity<>(result, HttpStatus.ACCEPTED);
+ }
+
+ @ApiOperation(value = "list restore-redundancy")
+ @PreAuthorize("@securityService.authorize('DATA', 'MANAGE')")
Review comment:
We are agreed that this is correct.
##
File path:
geode-web-management/src/main/java/org/apache/geode/management/internal/rest/controllers/RestoreRedundancyOperationController.java
##
@@ -0,0 +1,74 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ *
+ */
+
+package org.apache.geode.management.internal.rest.controllers;
+
+import static org.apache.geode.management.configuration.Links.URI_VERSION;
+import static
org.apache.geode.management.operation.RestoreRedundancyRequest.RESTORE_REDUNDANCY_ENDPOINT;
+
+import java.util.Optional;
+
+import io.swagger.annotations.ApiOperation;
+import org.springframework.http.HttpStatus;
+import org.springframework.http.ResponseEntity;
+import
[jira] [Commented] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147955#comment-17147955
]
ASF GitHub Bot commented on GEODE-8110:
---
kirklund opened a new pull request #5323:
URL: https://github.com/apache/geode/pull/5323
JMXMBeanReconnectDUnitTest has JMX Managers reconnecting so it will
very likely generate AlertingIOException during execution.
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
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147951#comment-17147951 ] ASF subversion and git services commented on GEODE-8095: Commit 161564ca82282637173774fd2da51fa5ce6a4af7 in geode's branch refs/heads/support/1.13 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=161564c ] GEODE-8095 backport to 1.13 (#5305) (cherry picked from commit 5732a1c1ef9c8ccb979770a963d5c4b1b7324f1a) Co-authored-by: Mark Hanson > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8095) Create restore redundancy and status redundancy REST API commands
[ https://issues.apache.org/jira/browse/GEODE-8095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147950#comment-17147950 ] ASF GitHub Bot commented on GEODE-8095: --- mhansonp merged pull request #5305: URL: https://github.com/apache/geode/pull/5305 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 > Create restore redundancy and status redundancy REST API commands > - > > Key: GEODE-8095 > URL: https://issues.apache.org/jira/browse/GEODE-8095 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Anilkumar Gingade >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > Add two REST API commands to allow redundancy to be restored and to check the > current redundancy status. > Similar to: https://issues.apache.org/jira/browse/GEODE-7954 > More on restore redundancy can be found at > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8298) member version comparison sense inconsistent when deciding on multicast
[
https://issues.apache.org/jira/browse/GEODE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8298:
Description:
Since about 2014 when we introduced the {{Version}} class to replace use of
{{short}}s all over the place for serialization versions, these two loops in
{{GMSMembership.processView()}} have used comparisons that disagree in sense:
{code}
// We perform the update under a global lock so that other
// incoming events will not be lost in terms of our global view.
latestViewWriteLock.lock();
try {
// first determine the version for multicast message serialization
VersionOrdinal version = Version.CURRENT;
for (final Entry internalIDLongEntry : surpriseMembers
.entrySet()) {
ID mbr = internalIDLongEntry.getKey();
final VersionOrdinal itsVersion = mbr.getVersionObject();
if (itsVersion != null && version.compareTo(itsVersion) < 0) {
version = itsVersion;
}
}
for (ID mbr : newView.getMembers()) {
final VersionOrdinal itsVersion = mbr.getVersionObject();
if (itsVersion != null && itsVersion.compareTo(version) < 0) {
version = mbr.getVersionObject();
}
}
disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
{code}
The goal here is to find the oldest version and if that version is older than
our local version we disable multicast. So we want to put the minimum into
{{version}}. So the first loop's comparison is wrong and the second one is
right.
While we are in here let's combine the two loops using a {{Iterable}}
combinator like Guava's {{Iterables.concat()}} or Apache Commons Collections
{{IterableUtils.chainedIterable()}} to combine the two iterables:
{{surpriseMembers}} and {{newView.getMembers()}} into one iterable. If we don't
want to introduce either of those two libraries into the product we can write
our own {{concat()}} utility like the one described here:
https://www.baeldung.com/java-combine-multiple-collections
Once we have the combined {{Iterable}} we can use something like
{{Collections.min()}} to find the minimum in one swell foop and this whole
thing collapses to one or two declarative expressions.
When this story is complete, the functionality will be in a separate method and
we'll have a unit test for it.
was:
Since about 2014 when we introduced the {{Version}} class to replace use of
{{short}}s all over the place for serialization versions, these two loops in
{{GMSMembership.processView()}} have used comparisons that disagree in sense:
{code}
// We perform the update under a global lock so that other
// incoming events will not be lost in terms of our global view.
latestViewWriteLock.lock();
try {
// first determine the version for multicast message serialization
VersionOrdinal version = Version.CURRENT;
for (final Entry internalIDLongEntry : surpriseMembers
.entrySet()) {
ID mbr = internalIDLongEntry.getKey();
final VersionOrdinal itsVersion = mbr.getVersionObject();
if (itsVersion != null && version.compareTo(itsVersion) < 0) {
version = itsVersion;
}
}
for (ID mbr : newView.getMembers()) {
final VersionOrdinal itsVersion = mbr.getVersionObject();
if (itsVersion != null && itsVersion.compareTo(version) < 0) {
version = mbr.getVersionObject();
}
}
disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
{code}
The goal here is to find the oldest version and if that version is older than
our local version we disable multicast. So we want to put the minimum into
{{version}}. So the first loop's comparison is wrong and the second one is
right.
While we are in here let's combine the two loops using a {{Iterable}}
combinator like Guava's {{Iterables.concat()}} or Apache Commons Collections
{{IterableUtils.chainedIterable()}} to combine the two iterables:
{{surpriseMembers}} and {{newView.getMembers()}} into one iterable. If we don't
want to introduce either of those two libraries into the product we can write
our own {{concat()}} utility like the one described here:
https://www.baeldung.com/java-combine-multiple-collections
Once we have the combined {{Iterable}} we can use something like
{{Collections.min()}} to find the minimum in one swell foop and this whole
thing collapses to one or two declarative expressions.
> member version comparison sense inconsistent when deciding on multicast
> ---
>
> Key: GEODE-8298
> URL: https://issues.apache.org/jira/browse/GEODE-8298
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Priority: Major
> Labels:
[jira] [Updated] (GEODE-8298) member version comparison sense inconsistent when deciding on multicast
[
https://issues.apache.org/jira/browse/GEODE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8298:
Labels: starter (was: )
> member version comparison sense inconsistent when deciding on multicast
> ---
>
> Key: GEODE-8298
> URL: https://issues.apache.org/jira/browse/GEODE-8298
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Priority: Major
> Labels: starter
>
> Since about 2014 when we introduced the {{Version}} class to replace use of
> {{short}}s all over the place for serialization versions, these two loops in
> {{GMSMembership.processView()}} have used comparisons that disagree in sense:
> {code}
> // We perform the update under a global lock so that other
> // incoming events will not be lost in terms of our global view.
> latestViewWriteLock.lock();
> try {
> // first determine the version for multicast message serialization
> VersionOrdinal version = Version.CURRENT;
> for (final Entry internalIDLongEntry : surpriseMembers
> .entrySet()) {
> ID mbr = internalIDLongEntry.getKey();
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && version.compareTo(itsVersion) < 0) {
> version = itsVersion;
> }
> }
> for (ID mbr : newView.getMembers()) {
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && itsVersion.compareTo(version) < 0) {
> version = mbr.getVersionObject();
> }
> }
> disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
> {code}
> The goal here is to find the oldest version and if that version is older than
> our local version we disable multicast. So we want to put the minimum into
> {{version}}. So the first loop's comparison is wrong and the second one is
> right.
> While we are in here let's combine the two loops using a {{Iterable}}
> combinator like Guava's {{Iterables.concat()}} or Apache Commons Collections
> {{IterableUtils.chainedIterable()}} to combine the two iterables:
> {{surpriseMembers}} and {{newView.getMembers()}} into one iterable. If we
> don't want to introduce either of those two libraries into the product we can
> write our own {{concat()}} utility like the one described here:
> https://www.baeldung.com/java-combine-multiple-collections
> Once we have the combined {{Iterable}} we can use something like
> {{Collections.min()}} to find the minimum in one swell foop and this whole
> thing collapses to one or two declarative expressions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8110) CI failure: JMXMBeanReconnectDUnitTest > serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with IOException
[
https://issues.apache.org/jira/browse/GEODE-8110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-8110:
-
Labels: GeodeOperationAPI flaky (was: )
> CI failure: JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns failed with
> IOException
>
>
> Key: GEODE-8110
> URL: https://issues.apache.org/jira/browse/GEODE-8110
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky
>
> DistributedTestOpenJDK8 build 158:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/158
> Failed with:
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2903
> org.apache.geode.alerting.internal.spi.AlertingIOException:
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:881)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: Cannot form connection to alert listener
> 172.17.0.6(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:978)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8312) Improve redis pub/sub capabilities
[ https://issues.apache.org/jira/browse/GEODE-8312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147930#comment-17147930 ] ASF GitHub Bot commented on GEODE-8312: --- dschneider-pivotal commented on a change in pull request #5316: URL: https://github.com/apache/geode/pull/5316#discussion_r447102688 ## File path: geode-redis/src/main/java/org/apache/geode/redis/internal/netty/ExecutionHandlerContext.java ## @@ -188,6 +188,13 @@ private void executeCommand(ChannelHandlerContext ctx, Command command) throws E return; } +if (command.isOfType(RedisCommandType.SELECT) Review comment: Jens said that code was mistakenly added. It has now been removed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve redis pub/sub capabilities > -- > > Key: GEODE-8312 > URL: https://issues.apache.org/jira/browse/GEODE-8312 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > * Add ability to [P]UNSUBSCRIBE from multiple channels. > * Match Redis semantics when subscribing to empty channel name. > * Interact with plain channel names as byte[]s instead of Strings (fixes > issues on Windows). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8099) Make ClusterConfiguration Service thread safe
[ https://issues.apache.org/jira/browse/GEODE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-8099: -- Assignee: Jinmei Liao > Make ClusterConfiguration Service thread safe > - > > Key: GEODE-8099 > URL: https://issues.apache.org/jira/browse/GEODE-8099 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anilkumar Gingade >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > When multiple cluster configuration clients (multiple rest clients) connects > and issue configuration commands, the cluster configuration should handle > concurrent request and modify/save/execute the configuration definition in > thread safe manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8099) Make ClusterConfiguration Service thread safe
[ https://issues.apache.org/jira/browse/GEODE-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-8099. Resolution: Fixed > Make ClusterConfiguration Service thread safe > - > > Key: GEODE-8099 > URL: https://issues.apache.org/jira/browse/GEODE-8099 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Anilkumar Gingade >Priority: Major > Labels: GeodeOperationAPI > Fix For: 1.14.0 > > > When multiple cluster configuration clients (multiple rest clients) connects > and issue configuration commands, the cluster configuration should handle > concurrent request and modify/save/execute the configuration definition in > thread safe manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8245) CI failure: ClientServerMiscSelectorDUnitTest.testPingWrongServer fails with java.lang.AssertionError: expected:<1> but was:<0>
[
https://issues.apache.org/jira/browse/GEODE-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes resolved GEODE-8245.
-
Fix Version/s: 1.14.0
Resolution: Fixed
The solution of GEODE-8176 applies to this ticket too.
> CI failure: ClientServerMiscSelectorDUnitTest.testPingWrongServer fails with
> java.lang.AssertionError: expected:<1> but was:<0>
> ---
>
> Key: GEODE-8245
> URL: https://issues.apache.org/jira/browse/GEODE-8245
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: flaky
> Fix For: 1.14.0
>
>
> CI:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0131/test-results/distributedTest/1591908487/
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$431/0x000840c63c40.run
> in VM 3 running on Host e740fc204386 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase.testPingWrongServer(ClientServerMiscDUnitTestBase.java:542)
> Caused by: java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase.lambda$testPingWrongServer$2200b406$2(ClientServerMiscDUnitTestBase.java:543)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
[
https://issues.apache.org/jira/browse/GEODE-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147814#comment-17147814
]
ASF subversion and git services commented on GEODE-8176:
Commit 34cfe04c35a49377db229c495a4a8b9afcb278f4 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=34cfe04 ]
GEODE-8176: Fix flakiness in testPingWrongServer (#5303)
> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
> Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: flaky
> Fix For: 1.14.0
>
>
> Failed in
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
> in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a
> blip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
[
https://issues.apache.org/jira/browse/GEODE-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147811#comment-17147811
]
ASF subversion and git services commented on GEODE-8176:
Commit 34cfe04c35a49377db229c495a4a8b9afcb278f4 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=34cfe04 ]
GEODE-8176: Fix flakiness in testPingWrongServer (#5303)
> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
> Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: flaky
> Fix For: 1.14.0
>
>
> Failed in
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
> in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a
> blip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
[
https://issues.apache.org/jira/browse/GEODE-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos resolved GEODE-8176.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
> Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: flaky
> Fix For: 1.14.0
>
>
> Failed in
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
> in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a
> blip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
[
https://issues.apache.org/jira/browse/GEODE-8176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147809#comment-17147809
]
ASF GitHub Bot commented on GEODE-8176:
---
jujoramos merged pull request #5303:
URL: https://github.com/apache/geode/pull/5303
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
> CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
> -
>
> Key: GEODE-8176
> URL: https://issues.apache.org/jira/browse/GEODE-8176
> Project: Geode
> Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: flaky
>
> Failed in
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testPingWrongServer[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
> in VM 3 running on Host c0a964e32781 with 5 VMs
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {noformat}
> I ran the test 200 times locally with no failure, so this is possibly just a
> blip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147708#comment-17147708
]
ASF GitHub Bot commented on GEODE-8240:
---
albertogpz commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r446910249
##
File path:
geode-core/src/upgradeTest/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
##
@@ -191,20 +207,26 @@ void doTestRollAll(String regionType, String objectType,
String startingVersion)
}
putAndVerify(objectType, server1, regionName, 0, 10, server2);
- locator = rollLocatorToCurrent(locator, hostName, locatorPorts[0],
getTestMethodName(),
- locatorString);
+ locator =
+ rollLocatorToCurrent(locator, hostName, locatorPort, locatorProps,
getTestMethodName(),
+ locatorString);
server1 = rollServerToCurrentAndCreateRegion(server1, regionType,
testingDirs[0],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, new int[] {locatorPort});
verifyValues(objectType, regionName, 0, 10, server1);
putAndVerify(objectType, server1, regionName, 5, 15, server2);
putAndVerify(objectType, server2, regionName, 10, 20, server1);
server2 = rollServerToCurrentAndCreateRegion(server2, regionType,
testingDirs[1],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, ports);
verifyValues(objectType, regionName, 0, 10, server2);
putAndVerify(objectType, server2, regionName, 15, 25, server1);
+ String shutDownCommand = "shutdown --include-locators=true";
Review comment:
The shutdown command had also issues. That's why the variable was there
initially in the test case.
Could you add the execution of the shutdown command after the ```list
members``` in order to verify that with your solution it works?
Otherwise, the variable must be removed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8292) CQs do not send back the right CREATE event but a UPDATE event once entry updated
[ https://issues.apache.org/jira/browse/GEODE-8292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-8292. --- Fix Version/s: 1.14.0 Assignee: Mario Kevo Resolution: Fixed > CQs do not send back the right CREATE event but a UPDATE event once entry > updated > - > > Key: GEODE-8292 > URL: https://issues.apache.org/jira/browse/GEODE-8292 > Project: Geode > Issue Type: Bug > Components: cq >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Fix For: 1.14.0 > > > When CQs are installed at Geode server, they dynamically analyzes incoming > updates/creates or deletion entries in the region. > If we have CQ something like "select * from /region i where i=1" and put some > values with i=0, and after that we change it to 1 and again to 0 several > times we got on listener some CREATE and some UPDATE when it fulfilling cq > condition. > The issue can be easily reproduced by geode-examples by modifying > geode-examples/cq/src/main/java/org/apache/geode_examples/cq/Example.java to > put some entries with transactions and then update it. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
