[jira] [Commented] (GEODE-8026) release improvements
[ https://issues.apache.org/jira/browse/GEODE-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093103#comment-17093103 ] ASF subversion and git services commented on GEODE-8026: Commit edcc07752bc5cd1c8e800ec70a792cc699ba7143 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=edcc077 ] GEODE-8026: release improvements (#5002) * make release artifact names consistent * verify tgz structure including presence of LICENSE and NOTICE and correct copyright in NOTICE * verify file size is reasonable * check that gfsh version --full contains correct SHA, version, and was built with an open-licensed JDK > release improvements > > > Key: GEODE-8026 > URL: https://issues.apache.org/jira/browse/GEODE-8026 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > From @abaker's review of Geode 1.12.0.RC4 > 1) Let's be consistent with names of source distribution and extensions (add > -src to examples, use .tgz consistently for all artifacts) > 2) NOTICE file copyright date needs to be updated for -native, > -benchmark, -examples...they still say 2018! > 3) Some of the version numbers in LICENSE need to updated to match, > also need to add asm-5.0.4.jar (a new transitive output from Spring > 5...intentional??) > The "rc" pipelineline could also check some of these, e.g. > Check file sizes are “reasonable” > Check the gfsh version --full reports correct SHA > Check the gfsh version --full does not contain the string Oracle > check that LICENSE and NOTICE file appear in each top-level dir > Check copyright year > Check that versions called out in LICENSE file match jar versions in the > release > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8026) release improvements
[ https://issues.apache.org/jira/browse/GEODE-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8026. - Fix Version/s: 1.13.0 Resolution: Fixed > release improvements > > > Key: GEODE-8026 > URL: https://issues.apache.org/jira/browse/GEODE-8026 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > > From @abaker's review of Geode 1.12.0.RC4 > 1) Let's be consistent with names of source distribution and extensions (add > -src to examples, use .tgz consistently for all artifacts) > 2) NOTICE file copyright date needs to be updated for -native, > -benchmark, -examples...they still say 2018! > 3) Some of the version numbers in LICENSE need to updated to match, > also need to add asm-5.0.4.jar (a new transitive output from Spring > 5...intentional??) > The "rc" pipelineline could also check some of these, e.g. > Check file sizes are “reasonable” > Check the gfsh version --full reports correct SHA > Check the gfsh version --full does not contain the string Oracle > check that LICENSE and NOTICE file appear in each top-level dir > Check copyright year > Check that versions called out in LICENSE file match jar versions in the > release > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7999) snapshots not available for support branches
[ https://issues.apache.org/jira/browse/GEODE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093106#comment-17093106 ] ASF subversion and git services commented on GEODE-7999: Commit 33ae60faef6d7c749246d9f0dd4f42baecb403b2 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=33ae60f ] GEODE-7999: make support branches publish snapshots (#4996) *make support branches publish snapshots * add missing step to update examples version when creating new support branch * update copyright year (both at branch creation and RC creation) > snapshots not available for support branches > > > Key: GEODE-7999 > URL: https://issues.apache.org/jira/browse/GEODE-7999 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Owen Nichols >Priority: Major > > Using maven to fetch org.apache.geode:geode-core:1.12.0-SNAPSHOT currently > returns an artifact from Feb 5 -- the last day develop was 1.12. Now that we > have long-lived support branches, we should continue publishing to the > snapshot repo from those support branches as well. > Changes needed: > change the release scripts to not remove -SNAPSHOT when cutting a support > branch > change the conditionals in the pipeline jinja template to keep the > PublishArtifacts job on support branches. > backport these changes to support/1.12 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8026) release improvements
[ https://issues.apache.org/jira/browse/GEODE-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8026: Description: >From @abaker's review of Geode 1.12.0.RC4 1) Let's be consistent with names of source distribution and extensions (add -src to examples, use .tgz consistently for all artifacts) 2) NOTICE file copyright date needs to be updated for -native, -benchmark, -examples...they still say 2018! The "rc" pipelineline could also check some of these, e.g. Check file sizes are “reasonable” Check the gfsh version --full reports correct SHA Check the gfsh version --full does not contain the string Oracle check that LICENSE and NOTICE file appear in each top-level dir Check copyright year was: >From @abaker's review of Geode 1.12.0.RC4 1) Let's be consistent with names of source distribution and extensions (add -src to examples, use .tgz consistently for all artifacts) 2) NOTICE file copyright date needs to be updated for -native, -benchmark, -examples...they still say 2018! 3) Some of the version numbers in LICENSE need to updated to match, also need to add asm-5.0.4.jar (a new transitive output from Spring 5...intentional??) The "rc" pipelineline could also check some of these, e.g. Check file sizes are “reasonable” Check the gfsh version --full reports correct SHA Check the gfsh version --full does not contain the string Oracle check that LICENSE and NOTICE file appear in each top-level dir Check copyright year Check that versions called out in LICENSE file match jar versions in the release > release improvements > > > Key: GEODE-8026 > URL: https://issues.apache.org/jira/browse/GEODE-8026 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > > From @abaker's review of Geode 1.12.0.RC4 > 1) Let's be consistent with names of source distribution and extensions (add > -src to examples, use .tgz consistently for all artifacts) > 2) NOTICE file copyright date needs to be updated for -native, > -benchmark, -examples...they still say 2018! > The "rc" pipelineline could also check some of these, e.g. > Check file sizes are “reasonable” > Check the gfsh version --full reports correct SHA > Check the gfsh version --full does not contain the string Oracle > check that LICENSE and NOTICE file appear in each top-level dir > Check copyright year > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7999) snapshots not available for support branches
[ https://issues.apache.org/jira/browse/GEODE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-7999. - Fix Version/s: 1.13.0 Resolution: Fixed > snapshots not available for support branches > > > Key: GEODE-7999 > URL: https://issues.apache.org/jira/browse/GEODE-7999 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > > Using maven to fetch org.apache.geode:geode-core:1.12.0-SNAPSHOT currently > returns an artifact from Feb 5 -- the last day develop was 1.12. Now that we > have long-lived support branches, we should continue publishing to the > snapshot repo from those support branches as well. > Changes needed: > change the release scripts to not remove -SNAPSHOT when cutting a support > branch > change the conditionals in the pipeline jinja template to keep the > PublishArtifacts job on support branches. > backport these changes to support/1.12 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7999) snapshots not available for support branches
[ https://issues.apache.org/jira/browse/GEODE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-7999: Fix Version/s: 1.12.1 > snapshots not available for support branches > > > Key: GEODE-7999 > URL: https://issues.apache.org/jira/browse/GEODE-7999 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Owen Nichols >Priority: Major > Fix For: 1.12.1, 1.13.0 > > > Using maven to fetch org.apache.geode:geode-core:1.12.0-SNAPSHOT currently > returns an artifact from Feb 5 -- the last day develop was 1.12. Now that we > have long-lived support branches, we should continue publishing to the > snapshot repo from those support branches as well. > Changes needed: > change the release scripts to not remove -SNAPSHOT when cutting a support > branch > change the conditionals in the pipeline jinja template to keep the > PublishArtifacts job on support branches. > backport these changes to support/1.12 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7944) Unable to deserialize membership id java.io.EOFException on locator only when debug is enabled and native client is used
[
https://issues.apache.org/jira/browse/GEODE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093219#comment-17093219
]
ASF GitHub Bot commented on GEODE-7944:
---
jvarenina opened a new pull request #593:
URL: https://github.com/apache/geode-native/pull/593
ClientProxyMembershipID correctly encapsulated within QueueConnectionRequest
to avoid "Unable to deserialize membership id java.io.EOFException" on
locator when trying to log recevied ClientProxyMembershipID on debug level
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
> Unable to deserialize membership id java.io.EOFException on locator only when
> debug is enabled and native client is used
>
>
> Key: GEODE-7944
> URL: https://issues.apache.org/jira/browse/GEODE-7944
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Attachments: locator.log, native_client.log
>
>
> During the creation of pool in geode native with subscription "enabled"
> exception java.io.EOFException is thrown on locator only when it is
> configured with _--log-level=debug_. On geode native this reflects with "No
> locators available". You can find native_client.log and locator.log in
> attachment.
> Native client code:
> {code:java}
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
> auto pool = poolFactory.addLocator("localhost", 10334)
> .setSubscriptionEnabled(true)
> .create("pool");
> {code}
> With java client everything works OK.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8027) Provide raw swagger JSON for managment API
[ https://issues.apache.org/jira/browse/GEODE-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093487#comment-17093487 ] ASF subversion and git services commented on GEODE-8027: Commit be8128512e88563f7a13449025e580c53a8160db in geode's branch refs/heads/develop from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=be81285 ] GEODE-8027: documentation script to attach swagger json (#5001) - Documentation page will now include the raw swagger json - This json file can be used to generate clients for the management API > Provide raw swagger JSON for managment API > -- > > Key: GEODE-8027 > URL: https://issues.apache.org/jira/browse/GEODE-8027 > Project: Geode > Issue Type: Task > Components: management >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Fix For: 1.13.0 > > > For our management API we have a wiki page with Swagger HTML documentation > for each version of our API. > They can be found here: > https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1 > For consumers of the API the pages should provide an attachment with raw > Swagger JSON that can be consumed by code generators. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8027) Provide raw swagger JSON for managment API
[ https://issues.apache.org/jira/browse/GEODE-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior resolved GEODE-8027. --- Resolution: Fixed > Provide raw swagger JSON for managment API > -- > > Key: GEODE-8027 > URL: https://issues.apache.org/jira/browse/GEODE-8027 > Project: Geode > Issue Type: Task > Components: management >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Fix For: 1.13.0 > > > For our management API we have a wiki page with Swagger HTML documentation > for each version of our API. > They can be found here: > https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1 > For consumers of the API the pages should provide an attachment with raw > Swagger JSON that can be consumed by code generators. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093582#comment-17093582
]
ASF GitHub Bot commented on GEODE-7565:
---
jujoramos commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r415863628
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/LocatorLoadSnapshot.java
##
@@ -50,7 +50,8 @@
private final Map serverGroupMap = new HashMap<>();
- private final Map> connectionLoadMap
= new HashMap<>();
+ private final Map>
connectionLoadMap =
Review comment:
This entire class has several modifications and new non-trivial methods,
we should add several tests to verify the correct behaviour.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedPingMessage.java
##
@@ -0,0 +1,79 @@
+/*
+ * 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 java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.distributed.internal.ClusterDistributionManager;
+import org.apache.geode.distributed.internal.HighPriorityDistributionMessage;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitor;
+import org.apache.geode.internal.cache.tier.sockets.ClientProxyMembershipID;
+import org.apache.geode.internal.serialization.DeserializationContext;
+import org.apache.geode.internal.serialization.SerializationContext;
+import org.apache.geode.internal.serialization.Version;
+
+public class DistributedPingMessage extends HighPriorityDistributionMessage {
Review comment:
This is a new class, unit and distribution tests are required.
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
##
@@ -641,4 +641,5 @@ public UUID getUUID() {
public interface HostnameResolver {
InetAddress getInetAddress(ServerLocation location) throws
UnknownHostException;
}
+
Review comment:
Unnecessary empty line here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Wrong management of receivers with same hostname-for-senders
>
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull
> Time Spent: 8h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
>
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not ch
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[ https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093584#comment-17093584 ] ASF GitHub Bot commented on GEODE-7565: --- jujoramos commented on a change in pull request #4978: URL: https://github.com/apache/geode/pull/4978#discussion_r415863628 ## File path: geode-core/src/main/java/org/apache/geode/distributed/internal/LocatorLoadSnapshot.java ## @@ -50,7 +50,8 @@ private final Map serverGroupMap = new HashMap<>(); - private final Map> connectionLoadMap = new HashMap<>(); + private final Map> connectionLoadMap = Review comment: This entire class has several modifications and new non-trivial methods, we should add tests to verify the correct behaviour. 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 > Wrong management of receivers with same hostname-for-senders > > > Key: GEODE-7565 > URL: https://issues.apache.org/jira/browse/GEODE-7565 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull > Time Spent: 8h > Remaining Estimate: 0h > > There is a problem with Geode WAN replication when GW receivers are > configured with the same hostname-for-senders and port on all servers. [ 1 ] > The problem experienced is that shutting down one server is stopping > replication to this cluster until the server is up again. This is because > Geode incorrectly assumes there are no more alive servers when just one of > them is down, because since they share hostname-for-senders and port, they > are treated as one same server. > Our proposal consists on expanding internal data in locators with enough > information to distinguish servers in the beforementioned use case. The same > intervention is likely needed in the client pools and possibly elsewhere in > the source code. > > [ 1 ] : The reason for such a setup is deploying Geode cluster on a > Kubernetes cluster where all GW receivers are reachable from the outside > world on the same VIP and port. Other kinds of configuration (different > hostname and/or different port for each GW receiver) are not cheap from OAM > and resources perspective in cloud native environments and also limit some > important use-cases (like scaling). > > Link to thread in DEV mailing list: > [https://markmail.org/thread/6qakx67rxiokdsec] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7944) Unable to deserialize membership id java.io.EOFException on locator only when debug is enabled and native client is used
[
https://issues.apache.org/jira/browse/GEODE-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093619#comment-17093619
]
ASF GitHub Bot commented on GEODE-7944:
---
pivotal-jbarrett commented on a change in pull request #593:
URL: https://github.com/apache/geode-native/pull/593#discussion_r415897067
##
File path: cppcache/test/QueueConnectionRequestTest.cpp
##
@@ -0,0 +1,78 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+
+#include
+
+#include
+
+#include
+
+#include "ByteArrayFixture.hpp"
+#include "DataOutputInternal.hpp"
+
+namespace apache {
+namespace geode {
+namespace client {
+
+inline std::string to_hex(const uint8_t* bytes, size_t len) {
+ std::stringstream ss;
+ ss << std::setfill('0') << std::hex;
+ for (size_t i(0); i < len; ++i) {
+ss << std::setw(2) << static_cast(bytes[i]);
+ }
+ return ss.str();
+}
+
+inline std::string to_hex(const DataOutput& out) {
+ return to_hex(out.getBuffer(), out.getBufferLength());
+}
+
+inline std::string int_to_hex_string(const int value) {
+ char hex[10];
+ sprintf(hex, "%x", value);
+ return std::string(hex);
+}
+
+TEST(QueueConnectionRequestTest, testToData) {
Review comment:
While I love to see another unit test, it seems like there should have
been a failing integration test. Some of the tests are disabled because they
never worked. Perhaps there is one that matches this failure.
##
File path: cppcache/src/QueueConnectionRequest.cpp
##
@@ -28,10 +28,10 @@ void QueueConnectionRequest::toData(DataOutput& output)
const {
output.writeString(m_serverGp);
output.write(static_cast(DSCode::FixedIDByte));
output.write(static_cast(DSCode::ClientProxyMembershipId));
- uint32_t buffLen = 0;
- output.writeBytes(reinterpret_cast(const_cast(
-m_membershipID.getDSMemberId(buffLen))),
-buffLen);
+ uint32_t memIdBufferLength = 0;
+ auto memIdBuffer = m_membershipID.getDSMemberId(memIdBufferLength);
Review comment:
```c++
const auto& dsMemberId = m_membershipID.getDSMemberId();
output.writeBytes(reinterpret_cast(dsMemberId.c_str()),
dsMemberId.size());
```
##
File path: cppcache/src/QueueConnectionRequest.cpp
##
@@ -28,10 +28,10 @@ void QueueConnectionRequest::toData(DataOutput& output)
const {
output.writeString(m_serverGp);
output.write(static_cast(DSCode::FixedIDByte));
output.write(static_cast(DSCode::ClientProxyMembershipId));
- uint32_t buffLen = 0;
- output.writeBytes(reinterpret_cast(const_cast(
-m_membershipID.getDSMemberId(buffLen))),
-buffLen);
+ uint32_t memIdBufferLength = 0;
+ auto memIdBuffer = m_membershipID.getDSMemberId(memIdBufferLength);
Review comment:
Internally the member ID is a std::string. This method is breaking it
into a c-string and length. Why not just modify the method to return a `const
std::string&`, you get the string and length encapsulated.
##
File path: cppcache/src/QueueConnectionRequest.cpp
##
@@ -28,10 +28,10 @@ void QueueConnectionRequest::toData(DataOutput& output)
const {
output.writeString(m_serverGp);
output.write(static_cast(DSCode::FixedIDByte));
output.write(static_cast(DSCode::ClientProxyMembershipId));
- uint32_t buffLen = 0;
- output.writeBytes(reinterpret_cast(const_cast(
-m_membershipID.getDSMemberId(buffLen))),
-buffLen);
+ uint32_t memIdBufferLength = 0;
+ auto memIdBuffer = m_membershipID.getDSMemberId(memIdBufferLength);
Review comment:
The use of `writeBytes` seems suspicious. Have you double checked the
Java side for who it writes and reads this string? There are only about 7 ways
we encode strings. ;)
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
> Unable to deserialize member
[jira] [Created] (GEODE-8028) refactor RedisCommandType
Darrel Schneider created GEODE-8028: --- Summary: refactor RedisCommandType Key: GEODE-8028 URL: https://issues.apache.org/jira/browse/GEODE-8028 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider The RedisCommandType enum is more complicated than it needs to be. It has a getDataType method that is never used. It lazily initializes the executor which means each enum instance needs its own subclass. The enum code itself is very verbose. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7990) Update to dependencies
[ https://issues.apache.org/jira/browse/GEODE-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093630#comment-17093630 ] ASF subversion and git services commented on GEODE-7990: Commit 8be5d4076188b44fdbb788b830d1af77da9fac29 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=8be5d40 ] GEODE-7990: Updates dependencies (#590) * ACE 6.5.8 * SQLite 3.31.1 * Xerces-C 3.2.3 > Update to dependencies > -- > > Key: GEODE-7990 > URL: https://issues.apache.org/jira/browse/GEODE-7990 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Update dependencies: > * ACE 6.5.8 > * SQLite 3.31.1 > * Xerces-C 3.2.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
Jagadeesh sivasankaran created GEODE-8029: - Summary: 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 Reporter: Jagadeesh sivasankaran Fix For: 1.9.0 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] [Commented] (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:comment-tabpanel&focusedCommentId=17093661#comment-17093661 ] Anthony Baker commented on GEODE-8029: -- Thanks for the bug report. To help you better, can you provide the following: * What was the version of geode? * What was the region configuration? * How many entries were in the region? * Do you have a complete log file you can share? * What was the JDK version? > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > Fix For: 1.9.0 > > > 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-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 ] Anthony Baker updated GEODE-8029: - Fix Version/s: (was: 1.9.0) > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > > 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] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093672#comment-17093672
]
ASF GitHub Bot commented on GEODE-8020:
---
bschuchardt opened a new pull request #4994:
URL: https://github.com/apache/geode/pull/4994
revert change in GEODE-6661 that made NioSslEngine use a direct buffer.
This class is not designed to share its buffer with a pool in
BufferPool. Connection is also modified to use a heap buffer for
reading encrypted SSL packets for consistency. New tests ensure that
these buffers are the correct type when using SSL or plain sockets.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> 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: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the
[jira] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093674#comment-17093674
]
ASF subversion and git services commented on GEODE-8020:
Commit ec8db54ad7f342542762beb8f3e912dff44e3a53 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec8db54 ]
GEODE-8020: buffer corruption in SSL communications (#4994)
revert change in GEODE-6661 that made NioSslEngine use a direct buffer.
This class is not designed to share its buffer with a pool in
BufferPool. Connection is also modified to use a heap buffer for
reading encrypted SSL packets for consistency. New tests ensure that
these buffers are the correct type when using SSL or plain sockets.
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> 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: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093675#comment-17093675 ] ASF subversion and git services commented on GEODE-6661: Commit ec8db54ad7f342542762beb8f3e912dff44e3a53 in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec8db54 ] GEODE-8020: buffer corruption in SSL communications (#4994) revert change in GEODE-6661 that made NioSslEngine use a direct buffer. This class is not designed to share its buffer with a pool in BufferPool. Connection is also modified to use a heap buffer for reading encrypted SSL packets for consistency. New tests ensure that these buffers are the correct type when using SSL or plain sockets. > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Bruce J Schuchardt >Priority: Major > Labels: performance > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-7981) Change default redis region type to PARTITION_REDUNDANT
[ https://issues.apache.org/jira/browse/GEODE-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reopened GEODE-7981: - The previous fix missed a spot in the docs > Change default redis region type to PARTITION_REDUNDANT > --- > > Key: GEODE-7981 > URL: https://issues.apache.org/jira/browse/GEODE-7981 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Darrel Schneider >Priority: Major > Labels: docs > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current default for the redis API region type is PARTITION, which doesn't > have any redundant copies. Since Geode can make the redis data highly > available with a PARTITION_REDUNDANT region type, we should make that the > default region type for ease of use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7981) Change default redis region type to PARTITION_REDUNDANT
[ https://issues.apache.org/jira/browse/GEODE-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093721#comment-17093721 ] ASF GitHub Bot commented on GEODE-7981: --- dschneider-pivotal opened a new pull request #5003: URL: https://github.com/apache/geode/pull/5003 Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change default redis region type to PARTITION_REDUNDANT > --- > > Key: GEODE-7981 > URL: https://issues.apache.org/jira/browse/GEODE-7981 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Darrel Schneider >Priority: Major > Labels: docs > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current default for the redis API region type is PARTITION, which doesn't > have any redundant copies. Since Geode can make the redis data highly > available with a PARTITION_REDUNDANT region type, we should make that the > default region type for ease of use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093727#comment-17093727 ] ASF GitHub Bot commented on GEODE-2484: --- pivotal-jbarrett opened a new pull request #594: URL: https://github.com/apache/geode-native/pull/594 Re-implement FairQueue as ConnectionQueue. * Use std::mutex. * Use std::recursive_mutex. * Adds unit test Benchmark Summary: New implementation is on par with ACE version where non-recursive mutex is used. New implementation is faster where recursive mutex is used. Benchmark Results: Run on (12 X 2900 MHz CPU s) CPU Caches: L1 Data 32K (x6) L1 Instruction 32K (x6) L2 Unified 262K (x6) L3 Unified 12582K (x1) Load Average: 27.65, 20.31, 16.34 -- Benchmark Time CPU Iterations -- ConnectionQueueBM_getUntil>/192/real_time/threads:96 9.88 ns 107 ns128204832 ConnectionQueueBM_getUntil>/192/real_time/threads:96 33.3 ns 365 ns 20599296 ConnectionQueueBM_getUntil>/192/real_time/threads:96 10.4 ns 111 ns127354080 ConnectionQueueBM_getUntil>/192/real_time/threads:96 15.5 ns 174 ns 71924448 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 > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- 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 ] Dale Emery updated GEODE-7851: -- Fix Version/s: 1.12.0 > 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.0, 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] [Commented] (GEODE-7591) potential hang
[
https://issues.apache.org/jira/browse/GEODE-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093726#comment-17093726
]
Bill Burcham commented on GEODE-7591:
-
[~jvarenina] how is it going with this bug?
> potential hang
> --
>
> Key: GEODE-7591
> URL: https://issues.apache.org/jira/browse/GEODE-7591
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Jakov Varenina
>Priority: Major
>
> This method in ClusterDistributionManager waits for a new membership view to
> be installed, but if the cache is being closed while waiting the method could
> hang because it only checks for cache closure if the object it's waiting on
> is notified. We should change the wait() to have a timeout so that the
> `stopper` is polled periodically
> {code:java}
> void waitForViewInstallation(long id) throws InterruptedException {
> if (id <= membershipViewIdAcknowledged) {
> return;
> }
> synchronized (membershipViewIdGuard) {
> while (membershipViewIdAcknowledged < id &&
> !stopper.isCancelInProgress()) {
> if (logger.isDebugEnabled()) {
> logger.debug("waiting for view {}. Current DM view processed by all
> listeners is {}", id,
> membershipViewIdAcknowledged);
> }
> membershipViewIdGuard.wait();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093728#comment-17093728 ] ASF GitHub Bot commented on GEODE-2484: --- pivotal-jbarrett commented on pull request #594: URL: https://github.com/apache/geode-native/pull/594#issuecomment-620101720 This one builds on top of https://github.com/apache/geode-native/pull/591 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 > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8020.
---
Fix Version/s: 1.13.0
Resolution: Fixed
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> 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: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7591) potential hang
[
https://issues.apache.org/jira/browse/GEODE-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093760#comment-17093760
]
Anthony Baker commented on GEODE-7591:
--
Is there a test case that demonstrates the suspected hang?
> potential hang
> --
>
> Key: GEODE-7591
> URL: https://issues.apache.org/jira/browse/GEODE-7591
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Jakov Varenina
>Priority: Major
>
> This method in ClusterDistributionManager waits for a new membership view to
> be installed, but if the cache is being closed while waiting the method could
> hang because it only checks for cache closure if the object it's waiting on
> is notified. We should change the wait() to have a timeout so that the
> `stopper` is polled periodically
> {code:java}
> void waitForViewInstallation(long id) throws InterruptedException {
> if (id <= membershipViewIdAcknowledged) {
> return;
> }
> synchronized (membershipViewIdGuard) {
> while (membershipViewIdAcknowledged < id &&
> !stopper.isCancelInProgress()) {
> if (logger.isDebugEnabled()) {
> logger.debug("waiting for view {}. Current DM view processed by all
> listeners is {}", id,
> membershipViewIdAcknowledged);
> }
> membershipViewIdGuard.wait();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-2484) Remove ACE from native client dependencies
[ https://issues.apache.org/jira/browse/GEODE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093761#comment-17093761 ] ASF GitHub Bot commented on GEODE-2484: --- lgtm-com[bot] commented on pull request #594: URL: https://github.com/apache/geode-native/pull/594#issuecomment-620124141 This pull request **introduces 4 alerts** and **fixes 1** when merging e709507e74709c7c515d808de485927ee42a50e5 into 8be5d4076188b44fdbb788b830d1af77da9fac29 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-cf6b76755c64e0506f8531e00221c50aae88bbda) **new alerts:** * 3 for Wrong type of arguments to formatting function * 1 for Virtual call from constructor or destructor **fixed alerts:** * 1 for Virtual call from constructor or destructor 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 > Remove ACE from native client dependencies > -- > > Key: GEODE-2484 > URL: https://issues.apache.org/jira/browse/GEODE-2484 > Project: Geode > Issue Type: Task > Components: native client >Reporter: David Kimura >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Remove ACE from native client dependencies. > Replace ACE usage with C++11 and/or Boost 1.63+ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093767#comment-17093767 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag commented on pull request #4826: URL: https://github.com/apache/geode/pull/4826#issuecomment-620132201 @nabarunnag testing zapier This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093769#comment-17093769 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag commented on pull request #4826: URL: https://github.com/apache/geode/pull/4826#issuecomment-620132875 @nabarunnag This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093768#comment-17093768 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag removed a comment on pull request #4826: URL: https://github.com/apache/geode/pull/4826#issuecomment-620132201 @nabarunnag testing zapier This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8030) CI Failure: HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
[
https://issues.apache.org/jira/browse/GEODE-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-8030:
-
Component/s: client queues
> CI Failure:
> HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> --
>
> Key: GEODE-8030
> URL: https://issues.apache.org/jira/browse/GEODE-8030
> Project: Geode
> Issue Type: Bug
> Components: client queues, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: flaky
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0220/test-results/distributedTest/1587763613/classes/org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.html#testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$260/1730948285.run
> in VM 1 running on Host c8674217ee1c 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.ha.HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR(HARQueueNewImplDUnitTest.java:683)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.Nati
[jira] [Created] (GEODE-8030) CI Failure: HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
Kirk Lund created GEODE-8030:
Summary: CI Failure:
HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
Key: GEODE-8030
URL: https://issues.apache.org/jira/browse/GEODE-8030
Project: Geode
Issue Type: Improvement
Components: tests
Reporter: Kirk Lund
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0220/test-results/distributedTest/1587763613/classes/org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.html#testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$260/1730948285.run
in VM 1 running on Host c8674217ee1c 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.ha.HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR(HARQueueNewImplDUnitTest.java:683)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispa
[jira] [Updated] (GEODE-8030) CI Failure: HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
[
https://issues.apache.org/jira/browse/GEODE-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-8030:
-
Issue Type: Bug (was: Improvement)
> CI Failure:
> HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> --
>
> Key: GEODE-8030
> URL: https://issues.apache.org/jira/browse/GEODE-8030
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0220/test-results/distributedTest/1587763613/classes/org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.html#testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$260/1730948285.run
> in VM 1 running on Host c8674217ee1c 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.ha.HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR(HARQueueNewImplDUnitTest.java:683)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] [Updated] (GEODE-8030) CI Failure: HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
[
https://issues.apache.org/jira/browse/GEODE-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-8030:
-
Labels: flaky (was: )
> CI Failure:
> HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> --
>
> Key: GEODE-8030
> URL: https://issues.apache.org/jira/browse/GEODE-8030
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: flaky
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0220/test-results/distributedTest/1587763613/classes/org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.html#testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$260/1730948285.run
> in VM 1 running on Host c8674217ee1c 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.ha.HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR(HARQueueNewImplDUnitTest.java:683)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImp
[jira] [Updated] (GEODE-8030) CI Failure: HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
[
https://issues.apache.org/jira/browse/GEODE-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-8030:
-
Description:
Link:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0220/test-results/distributedTest/1587763613/classes/org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.html#testHAEventWrapperDoesNotHoldCUMOnceInsideCMR
Partial stack:
{noformat}
Caused by: org.junit.ComparisonFailure: expected: but
was:
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.ha.HARQueueNewImplDUnitTest.verifyNullCUMReference(HARQueueNewImplDUnitTest.java:855)
at
org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest.lambda$testHAEventWrapperDoesNotHoldCUMOnceInsideCMR$bb17a952$4(HARQueueNewImplDUnitTest.java:683)
{noformat}
Full stack:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.ha.HARQueueNewImplDUnitTest$$Lambda$260/1730948285.run
in VM 1 running on Host c8674217ee1c 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.ha.HARQueueNewImplDUnitTest.testHAEventWrapperDoesNotHoldCUMOnceInsideCMR(HARQueueNewImplDUnitTest.java:683)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093791#comment-17093791 ] ASF subversion and git services commented on GEODE-7953: Commit 0f9918510b24f2169189936a92951b9bb4f313f1 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f99185 ] GEODE-7953: Restore Redundancy Internal API (#4909) * GEODE-7953: Restore Redundancy Internal API - Add RestoreRedundancyOperation interface and Impl class - Add RestoreRedundancyResults interface and Impl class - Add RegionRedundancyStatus interface and Impl class - Add accessor methods for RestoreRedundancyOperation to ResourceManager interface - Replace manually-synchronized sets in InternalResourceManager with ConcurrentHashMap - Add stats for restore redundancy operations - Add unit and DUnit tests for all the above Authored-by: Donal Evans > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093790#comment-17093790 ] ASF subversion and git services commented on GEODE-7953: Commit 0f9918510b24f2169189936a92951b9bb4f313f1 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f99185 ] GEODE-7953: Restore Redundancy Internal API (#4909) * GEODE-7953: Restore Redundancy Internal API - Add RestoreRedundancyOperation interface and Impl class - Add RestoreRedundancyResults interface and Impl class - Add RegionRedundancyStatus interface and Impl class - Add accessor methods for RestoreRedundancyOperation to ResourceManager interface - Replace manually-synchronized sets in InternalResourceManager with ConcurrentHashMap - Add stats for restore redundancy operations - Add unit and DUnit tests for all the above Authored-by: Donal Evans > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8027) Provide raw swagger JSON for managment API
[ https://issues.apache.org/jira/browse/GEODE-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093795#comment-17093795 ] ASF GitHub Bot commented on GEODE-8027: --- jinmeiliao commented on pull request #5001: URL: https://github.com/apache/geode/pull/5001#issuecomment-620147006 do we need to have the build process to pick up this json file and put it in the release folder? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Provide raw swagger JSON for managment API > -- > > Key: GEODE-8027 > URL: https://issues.apache.org/jira/browse/GEODE-8027 > Project: Geode > Issue Type: Task > Components: management >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Fix For: 1.13.0 > > > For our management API we have a wiki page with Swagger HTML documentation > for each version of our API. > They can be found here: > https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1 > For consumers of the API the pages should provide an attachment with raw > Swagger JSON that can be consumed by code generators. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17093796#comment-17093796 ] Jagadeesh sivasankaran commented on GEODE-8029: --- Version - 1.9.0 JDK - openjdk version "1.8.0_242" Total REgion - 10 Region Region - Most of the Regions have Entries in hundreds Except one region which have maximum 72000 Entries . Total Entires in all region should not exceed more than 100K. REgion, DiskStore, GatewaySender Configuration similar to all regions - create disk-store --name=clusteraHoStore --dir=/storage/data/ create gateway-sender --id=WODetails5 --parallel=false --remote-distributed-system-id=1 --maximum-queue-memory=1500 --enable-persistence=true --disk-store-name=clusteraHoStore --dispatcher-threads=10 --order-policy=PARTITION create region --name=workOrderDetails2 --gateway-sender-id=WODetails3 --type=REPLICATE_PERSISTENT_OVERFLOW --entry-idle-time-expiration=604800 --enable-statistics=true Let check with the My Manager, whether we can share log file. > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > > 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.create
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093800#comment-17093800
]
ASF GitHub Bot commented on GEODE-7954:
---
DonalEvans opened a new pull request #5004:
URL: https://github.com/apache/geode/pull/5004
- Add redundancyStatus method to RestoreRedundancyOperation interface
- Add RestoreRedundancyCommand
- Add StatusRedundancyCommand
- Add RedundancyCommandFunction for use by the new commands
- Create RedundancyCommandUtils to hold shared code used by both
commands
- Unit and DUnit tests for all the above
Authored-by: Donal Evans
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [x] Have you written or updated unit tests to verify your changes?
- [N/A] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * Redundancy is fully satisfied for all regions that were included, either
> explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> At least one bucket in a region has fewer than the configured number of
> redundant copies.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-reassign-primaries}} argument to determine if primaries should be
> reassigned or not during the operation. The default behaviour will be to
> reassign primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17093796#comment-17093796 ] Jagadeesh sivasankaran edited comment on GEODE-8029 at 4/27/20, 6:16 PM: - Version - 1.9.0 JDK - openjdk version "1.8.0_242" Total REgion - 10 Region Region - Most of the Regions have Entries in hundreds Except one region which have maximum 72000 Entries . Total Entires in all region should not exceed more than 100K. REgion, DiskStore, GatewaySender Configuration similar to all regions - create disk-store --name-geodeStore --dir=/app/data configure pdx --read-serialized=true --disk-store=geodeStore reate gateway-sender --id=PGWSenderHO --parallel=false --remote-distributed-system-id=1 --maximum-queue-memory=1500 --enable-persistence=true --disk-store-name=geodeStore --dispatcher-threads=10 --order-policy=PARTITION --manual-start=false create region --name=PGW_SLA_Region2 --gateway-sender-id=PGWSenderHO --type=REPLICATE_PERSISTENT --entry-time-to-live-expiration=604800 --entry-time-to-live-expiration-action=destroy --enable-statistics=true Let check with the My Manager, whether we can share log file. was (Author: jagan23527001): Version - 1.9.0 JDK - openjdk version "1.8.0_242" Total REgion - 10 Region Region - Most of the Regions have Entries in hundreds Except one region which have maximum 72000 Entries . Total Entires in all region should not exceed more than 100K. REgion, DiskStore, GatewaySender Configuration similar to all regions - create disk-store --name=clusteraHoStore --dir=/storage/data/ create gateway-sender --id=WODetails5 --parallel=false --remote-distributed-system-id=1 --maximum-queue-memory=1500 --enable-persistence=true --disk-store-name=clusteraHoStore --dispatcher-threads=10 --order-policy=PARTITION create region --name=workOrderDetails2 --gateway-sender-id=WODetails3 --type=REPLICATE_PERSISTENT_OVERFLOW --entry-idle-time-expiration=604800 --enable-statistics=true Let check with the My Manager, whether we can share log file. > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > > 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.xmlcac
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17093796#comment-17093796 ] Jagadeesh sivasankaran edited comment on GEODE-8029 at 4/27/20, 6:17 PM: - Version - 1.9.0 JDK - openjdk version "1.8.0_242" Total REgion - 10 Region Region - Most of the Regions have Entries in hundreds Except one region which have maximum 72000 Entries . Total Entires in all region should not exceed more than 100K. REgion, DiskStore, GatewaySender Configuration similar to all regions - create disk-store --name-geodeStore --dir=/app/data configure pdx --read-serialized=true --disk-store=geodeStore create gateway-sender --id=PGWSenderHO --parallel=false --remote-distributed-system-id=1 --maximum-queue-memory=1500 --enable-persistence=true --disk-store-name=geodeStore --dispatcher-threads=10 --order-policy=PARTITION --manual-start=false create region --name=PGW_SLA_Region2 --gateway-sender-id=PGWSenderHO --type=REPLICATE_PERSISTENT --entry-time-to-live-expiration=604800 --entry-time-to-live-expiration-action=destroy --enable-statistics=true Let check with the My Manager, whether we can share log file. was (Author: jagan23527001): Version - 1.9.0 JDK - openjdk version "1.8.0_242" Total REgion - 10 Region Region - Most of the Regions have Entries in hundreds Except one region which have maximum 72000 Entries . Total Entires in all region should not exceed more than 100K. REgion, DiskStore, GatewaySender Configuration similar to all regions - create disk-store --name-geodeStore --dir=/app/data configure pdx --read-serialized=true --disk-store=geodeStore reate gateway-sender --id=PGWSenderHO --parallel=false --remote-distributed-system-id=1 --maximum-queue-memory=1500 --enable-persistence=true --disk-store-name=geodeStore --dispatcher-threads=10 --order-policy=PARTITION --manual-start=false create region --name=PGW_SLA_Region2 --gateway-sender-id=PGWSenderHO --type=REPLICATE_PERSISTENT --entry-time-to-live-expiration=604800 --entry-time-to-live-expiration-action=destroy --enable-statistics=true Let check with the My Manager, whether we can share log file. > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > > 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
[jira] [Resolved] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-7953. Fix Version/s: 1.13.0 Resolution: Implemented > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 ] Jagadeesh sivasankaran updated GEODE-8029: -- Attachment: Screen Shot 2020-04-27 at 12.21.19 PM.png > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png > > > 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-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 ] Jagadeesh sivasankaran updated GEODE-8029: -- Attachment: Screen Shot 2020-04-27 at 12.21.19 PM.png > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=17093809#comment-17093809 ] Jagadeesh sivasankaran commented on GEODE-8029: --- Under the "/app/data" Diskstore we have lot backup files, is that getting loaded into hash and causing the issue. ? !Screen Shot 2020-04-27 at 12.21.19 PM.png! > 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 >Reporter: Jagadeesh sivasankaran >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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] [Commented] (GEODE-7591) potential hang
[
https://issues.apache.org/jira/browse/GEODE-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093810#comment-17093810
]
Bruce J Schuchardt commented on GEODE-7591:
---
[~abaker]no, there is no current test demonstrating the problem. That would be
part of the work for this ticket. This method is currently only used by
transaction failover to wait for locks to be cleaned up. The method waits on a
view-installation "guard" object for a new view to be installed but that might
not happen if the distribution manager is disconnecting.
> potential hang
> --
>
> Key: GEODE-7591
> URL: https://issues.apache.org/jira/browse/GEODE-7591
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Jakov Varenina
>Priority: Major
>
> This method in ClusterDistributionManager waits for a new membership view to
> be installed, but if the cache is being closed while waiting the method could
> hang because it only checks for cache closure if the object it's waiting on
> is notified. We should change the wait() to have a timeout so that the
> `stopper` is polled periodically
> {code:java}
> void waitForViewInstallation(long id) throws InterruptedException {
> if (id <= membershipViewIdAcknowledged) {
> return;
> }
> synchronized (membershipViewIdGuard) {
> while (membershipViewIdAcknowledged < id &&
> !stopper.isCancelInProgress()) {
> if (logger.isDebugEnabled()) {
> logger.debug("waiting for view {}. Current DM view processed by all
> listeners is {}", id,
> membershipViewIdAcknowledged);
> }
> membershipViewIdGuard.wait();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8021:
-
Assignee: Bruce J Schuchardt
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8021:
--
Component/s: membership
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Benjamin P Ross
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8021:
--
Affects Version/s: 1.12.0
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0
>Reporter: Benjamin P Ross
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093840#comment-17093840 ] ASF GitHub Bot commented on GEODE-7955: --- DonalEvans opened a new pull request #5005: URL: https://github.com/apache/geode/pull/5005 - Document restore redundancy gfsh command - Document status redundancy gfsh command - Document new RestoreRedundancyOperation API usage - Add rebalance and restore redundancy stats to stats list - Removed suggestion to use show metrics command to determine redudancy status - Removed suggestions to use rebalance when only restoring redundancy is wanted Authored-by: Donal Evans Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [x] Is your initial contribution a single, squashed commit? - [x] Does `gradlew build` run cleanly? - [N/A] Have you written or updated unit tests to verify your changes? - [N/A] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Documentation for restore redundancy internal API and gfsh commands > --- > > Key: GEODE-7955 > URL: https://issues.apache.org/jira/browse/GEODE-7955 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > Fully document the new features introduced in GEODE-7953 and GEODE-7954 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 ] Anthony Baker updated GEODE-8029: - Affects Version/s: 1.9.0 > 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 >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=17093857#comment-17093857 ] Anthony Baker commented on GEODE-8029: -- Are you creating and destroying a lot of keys? This should not be a problem, just trying to understand the use case. > 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 >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8020:
--
Fix Version/s: 1.12.1
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.1, 1.13.0
>
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> 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: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093867#comment-17093867 ] ASF subversion and git services commented on GEODE-6661: Commit 7850daf4f3f7a22dec2c832ad2e563ae6e0a268e in geode's branch refs/heads/support/1.12 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7850daf ] GEODE-8020: buffer corruption in SSL communications (#4994) revert change in GEODE-6661 that made NioSslEngine use a direct buffer. This class is not designed to share its buffer with a pool in BufferPool. Connection is also modified to use a heap buffer for reading encrypted SSL packets for consistency. New tests ensure that these buffers are the correct type when using SSL or plain sockets. (cherry picked from commit ec8db54ad7f342542762beb8f3e912dff44e3a53) > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Bruce J Schuchardt >Priority: Major > Labels: performance > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093866#comment-17093866
]
ASF subversion and git services commented on GEODE-8020:
Commit 7850daf4f3f7a22dec2c832ad2e563ae6e0a268e in geode's branch
refs/heads/support/1.12 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7850daf ]
GEODE-8020: buffer corruption in SSL communications (#4994)
revert change in GEODE-6661 that made NioSslEngine use a direct buffer.
This class is not designed to share its buffer with a pool in
BufferPool. Connection is also modified to use a heap buffer for
reading encrypted SSL packets for consistency. New tests ensure that
these buffers are the correct type when using SSL or plain sockets.
(cherry picked from commit ec8db54ad7f342542762beb8f3e912dff44e3a53)
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> 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: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17093868#comment-17093868 ] Jagadeesh sivasankaran commented on GEODE-8029: --- Hi Antony, YEs, In One region yes we create and destroy the keys . we would have destroyed more thant 2M+ entries in that region. Others are constant. > 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 >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17093868#comment-17093868 ] Jagadeesh sivasankaran edited comment on GEODE-8029 at 4/27/20, 7:21 PM: - Hi Antony, YEs, In One region we create and destroy the keys . we would have destroyed more than 2M+ entries in that region. Others are constant. was (Author: jagan23527001): Hi Antony, YEs, In One region yes we create and destroy the keys . we would have destroyed more thant 2M+ entries in that region. Others are constant. > 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 >Priority: Major > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png > > > 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] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093887#comment-17093887
]
ASF GitHub Bot commented on GEODE-7954:
---
jinmeiliao commented on a change in pull request #5004:
URL: https://github.com/apache/geode/pull/5004#discussion_r416090678
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/functions/RedundancyCommandFunction.java
##
@@ -0,0 +1,78 @@
+/*
+ * 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.cli.functions;
+
+import static
org.apache.geode.cache.control.RestoreRedundancyResults.Status.ERROR;
+
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Set;
+
+import org.apache.geode.cache.control.RestoreRedundancyOperation;
+import org.apache.geode.cache.control.RestoreRedundancyResults;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.management.cli.CliFunction;
+import org.apache.geode.management.internal.functions.CliFunctionResult;
+
+public class RedundancyCommandFunction extends CliFunction {
+ private static final long serialVersionUID = 5633636343813884996L;
+
+ @Override
+ public CliFunctionResult executeFunction(FunctionContext context) {
+Object[] arguments = context.getArguments();
+String[] includeRegions = (String[]) arguments[0];
+Set includeRegionsSet = null;
+if (includeRegions != null) {
+ includeRegionsSet = new HashSet<>(Arrays.asList(includeRegions));
+}
+
+String[] excludeRegions = (String[]) arguments[1];
+Set excludeRegionsSet = null;
+if (excludeRegions != null) {
+ excludeRegionsSet = new HashSet<>(Arrays.asList(excludeRegions));
+}
+
+boolean shouldReassignPrimaries = (boolean) arguments[2];
+
+boolean isStatusCommand = false;
+if (arguments.length > 3) {
+ isStatusCommand = (boolean) arguments[3];
+}
+
+RestoreRedundancyResults results;
+try {
+ RestoreRedundancyOperation redundancyOperation =
+
context.getCache().getResourceManager().createRestoreRedundancyOperation();
+ redundancyOperation.includeRegions(includeRegionsSet);
+ redundancyOperation.excludeRegions(excludeRegionsSet);
+ if (isStatusCommand) {
+results = redundancyOperation.redundancyStatus();
+ } else {
+redundancyOperation.shouldReassignPrimaries(shouldReassignPrimaries);
+results = redundancyOperation.start().get();
+ }
+} catch (Exception ex) {
Review comment:
consider get rid of the try/catch block, the CliFunction already handles
any exception thrown by the child in a uniform way.
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/StatusRedundancyCommand.java
##
@@ -0,0 +1,121 @@
+/*
+ * 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.cli.commands;
+
+import static
org.apache.geode.management.internal.cli.commands.RedundancyCommandUtils.REDUNDANCY_COMMAND_ADDED_VERSION;
+import static
org.apache.geode.management.internal.functions.CliFunctionResult.StatusState.ERROR;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.springframework.shell.core.annotation.CliCommand;
+import org.springframework.shell.core.annotation.CliOption;
+
+import or
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093893#comment-17093893 ] ASF GitHub Bot commented on GEODE-7953: --- DonalEvans opened a new pull request #5006: URL: https://github.com/apache/geode/pull/5006 This reverts commit 0f9918510b24f2169189936a92951b9bb4f313f1. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7981) Change default redis region type to PARTITION_REDUNDANT
[ https://issues.apache.org/jira/browse/GEODE-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7981. - Resolution: Fixed > Change default redis region type to PARTITION_REDUNDANT > --- > > Key: GEODE-7981 > URL: https://issues.apache.org/jira/browse/GEODE-7981 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Darrel Schneider >Priority: Major > Labels: docs > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current default for the redis API region type is PARTITION, which doesn't > have any redundant copies. Since Geode can make the redis data highly > available with a PARTITION_REDUNDANT region type, we should make that the > default region type for ease of use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7981) Change default redis region type to PARTITION_REDUNDANT
[ https://issues.apache.org/jira/browse/GEODE-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093899#comment-17093899 ] ASF subversion and git services commented on GEODE-7981: Commit ccc3f46d74806ceccb551588bc2b5a4773ffd181 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccc3f46 ] GEODE-7981: fix docs for redis PARTITION_REDUNDANT (#5003) > Change default redis region type to PARTITION_REDUNDANT > --- > > Key: GEODE-7981 > URL: https://issues.apache.org/jira/browse/GEODE-7981 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Darrel Schneider >Priority: Major > Labels: docs > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current default for the redis API region type is PARTITION, which doesn't > have any redundant copies. Since Geode can make the redis data highly > available with a PARTITION_REDUNDANT region type, we should make that the > default region type for ease of use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7964) Upgrade mockito dependency from 2.23.0 to 3.3.3
[ https://issues.apache.org/jira/browse/GEODE-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-7964. -- Fix Version/s: 1.13.0 Resolution: Fixed > Upgrade mockito dependency from 2.23.0 to 3.3.3 > --- > > Key: GEODE-7964 > URL: https://issues.apache.org/jira/browse/GEODE-7964 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Upgrade mockito dependency from 2.23.0 to 3.3.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093907#comment-17093907 ] ASF subversion and git services commented on GEODE-7953: Commit 9fad2c0fba51f1a8beb24c311255dfa55a537c99 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9fad2c0 ] Revert "GEODE-7953: Restore Redundancy Internal API (#4909)" (#5006) This reverts commit 0f9918510b24f2169189936a92951b9bb4f313f1. > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7935) CI Failure: GridAdvisorDUnitTest.test2by2usingGroups
[
https://issues.apache.org/jira/browse/GEODE-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7935.
Fix Version/s: 1.13.0
Resolution: Fixed
Added awaits...
> CI Failure: GridAdvisorDUnitTest.test2by2usingGroups
>
>
> Key: GEODE-7935
> URL: https://issues.apache.org/jira/browse/GEODE-7935
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> GridAdvisorDUnitTest.test2by2usingGroups failed with the following output:
> {code:java}
> org.apache.geode.internal.cache.GridAdvisorDUnitTest > test2by2usingGroups
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.GridAdvisorDUnitTest$$Lambda$75/1898684933.run
> in VM 3 running on Host be2727401e1b 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.GridAdvisorDUnitTest.test2by2usingGroups(GridAdvisorDUnitTest.java:306)
> Caused by:
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> 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.GridAdvisorDUnitTest.verifyLocatorStopped(GridAdvisorDUnitTest.java:427)
> at
> org.apache.geode.internal.cache.GridAdvisorDUnitTest.lambda$test2by2usingGroups$bb17a952$2(GridAdvisorDUnitTest.java:306)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1672
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1561
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1504
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7988) AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is failing in mass test run
[
https://issues.apache.org/jira/browse/GEODE-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7988:
--
Assignee: (was: Mark Hanson)
> AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is
> failing in mass test run
> ---
>
> Key: GEODE-7988
> URL: https://issues.apache.org/jira/browse/GEODE-7988
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> testClientDynamicallyDropsStoppedLocator
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1993
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1940
> {noformat}
>
> This is also reproducible using dunitrunner.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7988) AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is failing in mass test run
[
https://issues.apache.org/jira/browse/GEODE-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7988:
--
Assignee: Mark Hanson (was: Ivan Godwin)
> AutoConnectionSourceDUnitTest. testClientDynamicallyDropsStoppedLocator is
> failing in mass test run
> ---
>
> Key: GEODE-7988
> URL: https://issues.apache.org/jira/browse/GEODE-7988
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> testClientDynamicallyDropsStoppedLocator
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1993
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1940
> {noformat}
>
> This is also reproducible using dunitrunner.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093916#comment-17093916
]
ASF GitHub Bot commented on GEODE-7954:
---
DonalEvans commented on a change in pull request #5004:
URL: https://github.com/apache/geode/pull/5004#discussion_r416133323
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/functions/RedundancyCommandFunction.java
##
@@ -0,0 +1,78 @@
+/*
+ * 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.cli.functions;
+
+import static
org.apache.geode.cache.control.RestoreRedundancyResults.Status.ERROR;
+
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Set;
+
+import org.apache.geode.cache.control.RestoreRedundancyOperation;
+import org.apache.geode.cache.control.RestoreRedundancyResults;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.management.cli.CliFunction;
+import org.apache.geode.management.internal.functions.CliFunctionResult;
+
+public class RedundancyCommandFunction extends CliFunction {
+ private static final long serialVersionUID = 5633636343813884996L;
+
+ @Override
+ public CliFunctionResult executeFunction(FunctionContext context) {
+Object[] arguments = context.getArguments();
+String[] includeRegions = (String[]) arguments[0];
+Set includeRegionsSet = null;
+if (includeRegions != null) {
+ includeRegionsSet = new HashSet<>(Arrays.asList(includeRegions));
+}
+
+String[] excludeRegions = (String[]) arguments[1];
+Set excludeRegionsSet = null;
+if (excludeRegions != null) {
+ excludeRegionsSet = new HashSet<>(Arrays.asList(excludeRegions));
+}
+
+boolean shouldReassignPrimaries = (boolean) arguments[2];
+
+boolean isStatusCommand = false;
+if (arguments.length > 3) {
+ isStatusCommand = (boolean) arguments[3];
+}
+
+RestoreRedundancyResults results;
+try {
+ RestoreRedundancyOperation redundancyOperation =
+
context.getCache().getResourceManager().createRestoreRedundancyOperation();
+ redundancyOperation.includeRegions(includeRegionsSet);
+ redundancyOperation.excludeRegions(excludeRegionsSet);
+ if (isStatusCommand) {
+results = redundancyOperation.redundancyStatus();
+ } else {
+redundancyOperation.shouldReassignPrimaries(shouldReassignPrimaries);
+results = redundancyOperation.start().get();
+ }
+} catch (Exception ex) {
Review comment:
Will do
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 gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * Redundancy is fully satisfied for all regions that were included, either
> explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bu
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093914#comment-17093914
]
ASF GitHub Bot commented on GEODE-7954:
---
DonalEvans commented on a change in pull request #5004:
URL: https://github.com/apache/geode/pull/5004#discussion_r416133022
##
File path:
geode-gfsh/src/test/java/org/apache/geode/management/internal/cli/commands/RestoreRedundancyCommandTest.java
##
@@ -0,0 +1,256 @@
+/*
+ * 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.cli.commands;
+
+import static org.apache.geode.management.cli.Result.Status.ERROR;
+import static org.apache.geode.management.cli.Result.Status.OK;
+import static
org.apache.geode.management.internal.cli.commands.RedundancyCommandUtils.REDUNDANCY_COMMAND_ADDED_VERSION;
+import static org.hamcrest.CoreMatchers.everyItem;
+import static org.hamcrest.CoreMatchers.is;
+import static org.junit.Assert.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyBoolean;
+import static org.mockito.ArgumentMatchers.eq;
+import static org.mockito.Mockito.doAnswer;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.times;
+import static org.mockito.Mockito.verify;
+import static org.mockito.Mockito.when;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+
+import org.junit.Before;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.management.internal.functions.CliFunctionResult;
+import
org.apache.geode.management.internal.operation.RebalanceOperationPerformer;
+
+public class RestoreRedundancyCommandTest {
Review comment:
The results should be being examined in the DUnit tests for these
commands, so the unit tests are just intended to confirm that the methods in
the class are providing the expected behaviour.
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 gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * Redundancy is fully satisfied for all regions that were included, either
> explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> At least one bucket in a region has fewer than the configured number of
> redundant copies.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093915#comment-17093915
]
ASF GitHub Bot commented on GEODE-7954:
---
DonalEvans commented on a change in pull request #5004:
URL: https://github.com/apache/geode/pull/5004#discussion_r416133248
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/RestoreRedundancyCommand.java
##
@@ -0,0 +1,128 @@
+/*
+ * 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.cli.commands;
+
+import static
org.apache.geode.management.internal.cli.commands.RedundancyCommandUtils.REDUNDANCY_COMMAND_ADDED_VERSION;
+import static
org.apache.geode.management.internal.functions.CliFunctionResult.StatusState.ERROR;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import org.springframework.shell.core.annotation.CliCommand;
+import org.springframework.shell.core.annotation.CliOption;
+
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.management.cli.CliMetaData;
+import org.apache.geode.management.cli.SingleGfshCommand;
+import
org.apache.geode.management.internal.cli.functions.RedundancyCommandFunction;
+import org.apache.geode.management.internal.cli.result.model.ResultModel;
+import org.apache.geode.management.internal.functions.CliFunctionResult;
+import org.apache.geode.management.internal.i18n.CliStrings;
+import
org.apache.geode.management.internal.operation.RebalanceOperationPerformer;
+import org.apache.geode.management.internal.security.ResourceOperation;
+import org.apache.geode.security.ResourcePermission;
+
+public class RestoreRedundancyCommand extends SingleGfshCommand {
Review comment:
Thanks for catching this.
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 gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * Redundancy is fully satisfied for all regions that were included, either
> explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> At least one bucket in a region has fewer than the configured number of
> redundant copies.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, simi
[jira] [Assigned] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-8031: -- Assignee: Donal Evans > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails due to SSL not enabled for locator > -- > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator
Donal Evans created GEODE-8031: -- Summary: CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator Key: GEODE-8031 URL: https://issues.apache.org/jira/browse/GEODE-8031 Project: Geode Issue Type: Bug Reporter: Donal Evans org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > testNewSSLConfigSSLComponentLocator FAILED java.lang.AssertionError at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertTrue(Assert.java:52) at org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) This failure is possibly caused by previously run tests not closing the static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8031: --- Affects Version/s: 1.13.0 > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails due to SSL not enabled for locator > -- > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Priority: Major > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8031: --- Summary: CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator (was: CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator) > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails on Windows due to SSL not enabled for locator > - > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17093934#comment-17093934 ] Jagadeesh sivasankaran commented on GEODE-8029: --- Server is getting closed when it loads the data from diskstore which is very old ( 2 years old drf files). Attached the log file [^server02.log] [info 2020/04/27 20:57:57.485 UTC tid=0x1] Recovering oplog#6 /app/provServerHO2/data/BACKUPgeodeStore_6.drf for disk store geodeStore. [info 2020/04/27 20:57:58.292 UTC tid=0x1] Recovering oplog#5 /app/provServerHO2/data/BACKUPgeodeStore_5.drf for disk store geodeStore. [error 2020/04/27 21:01:58.716 UTC tid=0x1] Cache initialization for GemFireCache[id = 847839957; isClosing = false; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because: java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75) [info 2020/04/27 21:01:58.743 UTC tid=0x1] GemFireCache[id = 847839957; isClosing = true; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60]: Now closing. [info 2020/04/27 21:01:58.792 UTC tid=0x1] Shutting down DistributionManager .79.149(provServerHO2:9798):1024. [info 2020/04/27 21:01:58.896 UTC tid=0x1] Now closing distribution for .79.149(provServerHO2:9798):1024 [info 2020/04/27 21:01:58.897 UTC tid=0x1] Stopping membership services [info 2020/04/27 21:01:58.901 UTC tid=0x1f] GMSHealthMonitor server thread exiting [info 2020/04/27 21:01:58.915 UTC tid=0x1] DistributionManager stopped in 123ms. [info 2020/04/27 21:01:58.916 UTC tid=0x1] Marking DistributionManager .79.149(provServerHO2:9798):1024 as closed. > 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 >Priority: Major > 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(
[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 ] Jagadeesh sivasankaran updated GEODE-8029: -- Attachment: server02.log > 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 >Priority: Major > 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] [Comment Edited] (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:comment-tabpanel&focusedCommentId=17093934#comment-17093934 ] Jagadeesh sivasankaran edited comment on GEODE-8029 at 4/27/20, 9:19 PM: - *Server is getting closed when it loads the data from diskstore which is very old ( 2 years old drf files). Attached the log file* [^server02.log] [info 2020/04/27 20:57:57.485 UTC tid=0x1] Recovering oplog#6 /app/provServerHO2/data/BACKUPgeodeStore_6.drf for disk store geodeStore. [info 2020/04/27 20:57:58.292 UTC tid=0x1] Recovering oplog#5 /app/provServerHO2/data/BACKUPgeodeStore_5.drf for disk store geodeStore. [error 2020/04/27 21:01:58.716 UTC tid=0x1] Cache initialization for GemFireCache[id = 847839957; isClosing = false; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because: java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75) [info 2020/04/27 21:01:58.743 UTC tid=0x1] GemFireCache[id = 847839957; isClosing = true; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60]: Now closing. [info 2020/04/27 21:01:58.792 UTC tid=0x1] Shutting down DistributionManager .79.149(provServerHO2:9798):1024. [info 2020/04/27 21:01:58.896 UTC tid=0x1] Now closing distribution for .79.149(provServerHO2:9798):1024 [info 2020/04/27 21:01:58.897 UTC tid=0x1] Stopping membership services [info 2020/04/27 21:01:58.901 UTC tid=0x1f] GMSHealthMonitor server thread exiting [info 2020/04/27 21:01:58.915 UTC tid=0x1] DistributionManager stopped in 123ms. [info 2020/04/27 21:01:58.916 UTC tid=0x1] Marking DistributionManager .79.149(provServerHO2:9798):1024 as closed. was (Author: jagan23527001): Server is getting closed when it loads the data from diskstore which is very old ( 2 years old drf files). Attached the log file [^server02.log] [info 2020/04/27 20:57:57.485 UTC tid=0x1] Recovering oplog#6 /app/provServerHO2/data/BACKUPgeodeStore_6.drf for disk store geodeStore. [info 2020/04/27 20:57:58.292 UTC tid=0x1] Recovering oplog#5 /app/provServerHO2/data/BACKUPgeodeStore_5.drf for disk store geodeStore. [error 2020/04/27 21:01:58.716 UTC tid=0x1] Cache initialization for GemFireCache[id = 847839957; isClosing = false; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because: java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75) [info 2020/04/27 21:01:58.743 UTC tid=0x1] GemFireCache[id = 847839957; isClosing = true; isShutDownAll = false; created = Mon Apr 27 20:54:11 UTC 2020; server = false; copyOnRead = false; lockLease = 120; lockTimeout = 60]: Now closing. [info 2020/04/27 21:01:58.792 UTC tid=0x1] Shutting down DistributionManager .79.149(provServerHO2:9798):1024. [info 2020/04/27 21:01:58.896 UTC tid=0x1] Now closing distribution for .79.149(provServerHO2:9798):1024 [info 2020/04/27 21:01:58.897 UTC tid=0x1] Stopping membership services [info 2020/04/27 21:01:58.901 UTC tid=0x1f] GMSHealthMonitor server thread exiting [info 2020/04/27 21:01:58.915 UTC tid=0x1] DistributionManager stopped in 123ms. [info 2020/04/27 21:01:58.916 UTC tid=0x1] Marking DistributionManager .79.149(provServerHO2:9798):1024 as closed. > 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 >Priority: Major > 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.
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17093937#comment-17093937 ] Jagadeesh sivasankaran commented on GEODE-8029: --- *If i move this file "/app/provServerHO2/data/BACKUPgeodeStore_5.drf" to another Directory and start the Cache server, am getting below error.* 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.Illega*lStateException: The following required files could not be found: *.drf files with these ids: [5].* at org.apache.geode.internal.cache.DiskInitFile.verifyOplogs(DiskInitFile.java:832) at org.apache.geode.internal.cache.DiskInitFile.verifyOplogs(DiskInitFile.java:805) > 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 >Priority: Major > 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.geo
[jira] [Created] (GEODE-8032) Unit tests should not pollute the environment
Kirk Lund created GEODE-8032: Summary: Unit tests should not pollute the environment Key: GEODE-8032 URL: https://issues.apache.org/jira/browse/GEODE-8032 Project: Geode Issue Type: Bug Components: tests Reporter: Kirk Lund Unit tests should not pollute the environment. >From https://www.artima.com/weblogs/viewpost.jsp?thread=126923: A test is not a unit test if: * It talks to the database * It communicates across the network * It touches the file system * It can't run at the same time as any of your other unit tests * You have to do special things to your environment (such as editing config files) to run it. Tests that do these things are good but they should be an integration or system test instead of a unit test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8032) Unit tests should not pollute the environment
[ https://issues.apache.org/jira/browse/GEODE-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-8032: Assignee: Kirk Lund > Unit tests should not pollute the environment > - > > Key: GEODE-8032 > URL: https://issues.apache.org/jira/browse/GEODE-8032 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Unit tests should not pollute the environment. > From https://www.artima.com/weblogs/viewpost.jsp?thread=126923: > A test is not a unit test if: > * It talks to the database > * It communicates across the network > * It touches the file system > * It can't run at the same time as any of your other unit tests > * You have to do special things to your environment (such as editing config > files) to run it. > Tests that do these things are good but they should be an integration or > system test instead of a unit test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8016) Replace Maven SNAPSHOT with enumerated build-id artifacts
[ https://issues.apache.org/jira/browse/GEODE-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton updated GEODE-8016: --- Description: To better support repeatable builds in CI, publish artifacts in the form `1.2.3-build.123` instead of `1.2.3-SNAPSHOT` with the SNAPSHOT dynamically changing. As an example, the `geode-examples` pipeline would be able to grab a distinct artifact for build-and-test, instead of an unrepeatable, invisibly rolling `SNAPSHOT`. (was: To better support repeatable builds in CI, publish artifacts in the form `1.2.3-build.123` instead of `1.2.3-SNAPSHOT` with the SNAPSHOT dynamically changing. ) > Replace Maven SNAPSHOT with enumerated build-id artifacts > - > > Key: GEODE-8016 > URL: https://issues.apache.org/jira/browse/GEODE-8016 > Project: Geode > Issue Type: Task > Components: build, ci >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > > To better support repeatable builds in CI, publish artifacts in the form > `1.2.3-build.123` instead of `1.2.3-SNAPSHOT` with the SNAPSHOT dynamically > changing. As an example, the `geode-examples` pipeline would be able to grab > a distinct artifact for build-and-test, instead of an unrepeatable, invisibly > rolling `SNAPSHOT`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8027) Provide raw swagger JSON for managment API
[ https://issues.apache.org/jira/browse/GEODE-8027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093984#comment-17093984 ] ASF GitHub Bot commented on GEODE-8027: --- jmelchio commented on pull request #5001: URL: https://github.com/apache/geode/pull/5001#issuecomment-620268819 > do we need to have the build process to pick up this json file and put it in the release folder? I'm not sure to be honest. I looked at the related ticket from the K8S team and it seems to me that they need to their own repo for the client code and at that point something can be added to the script to push the swagger JSON to that repo. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Provide raw swagger JSON for managment API > -- > > Key: GEODE-8027 > URL: https://issues.apache.org/jira/browse/GEODE-8027 > Project: Geode > Issue Type: Task > Components: management >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Fix For: 1.13.0 > > > For our management API we have a wiki page with Swagger HTML documentation > for each version of our API. > They can be found here: > https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1 > https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1 > For consumers of the API the pages should provide an attachment with raw > Swagger JSON that can be consumed by code generators. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093985#comment-17093985
]
ASF subversion and git services commented on GEODE-8021:
Commit 022f6049fc84df3ae929cde0dec20b5aa2b9edb3 in geode's branch
refs/heads/feature/GEODE-8021 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=022f604 ]
GEODE-8021: CI Failure: CloseConnectionTest.
sharedSenderShouldRecoverFromClosedSocket
fixing a marginally flaky test
- ensure no bleed-through from other tests in ConnectionTable's
ThreadLocal, which would cause getConnection to return the wrong
sort of Connection
- since Connections are multi-threaded and the state we're looking for
is set by a background thread, use GeodeAwaitility to wait for the
condition to be set.
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0
>Reporter: Benjamin P Ross
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093987#comment-17093987 ] ASF GitHub Bot commented on GEODE-8031: --- DonalEvans opened a new pull request #5007: URL: https://github.com/apache/geode/pull/5007 - Ensure that any existing SocketCreatorFactory instances created by previously-run tests are closed before each test execution in SocketFactoryCreatorJUnitTest Authored-by: Donal Evans Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails on Windows due to SSL not enabled for locator > - > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093988#comment-17093988
]
ASF GitHub Bot commented on GEODE-8021:
---
bschuchardt opened a new pull request #5008:
URL: https://github.com/apache/geode/pull/5008
…rFromClosedSocket
fixing a marginally flaky test
- ensure no bleed-through from other tests in ConnectionTable's
ThreadLocal, which would cause getConnection to return the wrong
sort of Connection
- since Connections are multi-threaded and the state we're looking for
is set by a background thread, use GeodeAwaitility to wait for the
condition to be set.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [x] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0
>Reporter: Benjamin P Ross
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093997#comment-17093997 ] ASF subversion and git services commented on GEODE-8031: Commit ee210190854d54ceef26440669f64a8b0dc2766d in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee21019 ] GEODE-8031: Close lingering SocketCreatorFactory instances (#5007) - Ensure that any existing SocketCreatorFactory instances created by previously-run tests are closed before each test execution in SocketFactoryCreatorJUnitTest Authored-by: Donal Evans > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails on Windows due to SSL not enabled for locator > - > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094005#comment-17094005 ] ASF GitHub Bot commented on GEODE-7953: --- DonalEvans opened a new pull request #5010: URL: https://github.com/apache/geode/pull/5010 - Add RestoreRedundancyOperation interface and Impl class - Add RestoreRedundancyResults interface and Impl class - Add RegionRedundancyStatus interface and Impl class - Add accessor methods for RestoreRedundancyOperation to ResourceManager interface - Replace manually-synchronized sets in InternalResourceManager with ConcurrentHashMap - Add stats for restore redundancy operations - Add unit and DUnit tests for all the above This commit undoes the previous revert of these changes. Authored-by: Donal Evans Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [x] Is your initial contribution a single, squashed commit? - [x] Does `gradlew build` run cleanly? - [x] Have you written or updated unit tests to verify your changes? - [N/A] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8032) Unit tests should not pollute the environment
[ https://issues.apache.org/jira/browse/GEODE-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094006#comment-17094006 ] ASF GitHub Bot commented on GEODE-8032: --- kirklund opened a new pull request #5011: URL: https://github.com/apache/geode/pull/5011 I found 3 tests named *IntegrationTests in src/test that need to move: * geode-core/src/test/java/org/apache/geode/distributed/internal/InternalDistributedSystemIntegrationTest.java * geode-protobuf/src/test/java/org/apache/geode/internal/protocol/protobuf/v1/operations/OqlQueryRequestOperationHandlerIntegrationTest.java* geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherIntegrationTest.java These are unit tests that are better off renamed and moved to src/integrationTest because they touch several Geode classes including singletons:* geode-core/src/test/java/org/apache/geode/distributed/internal/InternalLocatorTest.java* geode-core/src/test/java/org/apache/geode/distributed/internal/locks/DLockServiceJUnitTest.java This one creates a full DistributedSystem stack so it belongs in src/integrationTest:* geode-core/src/test/java/org/apache/geode/distributed/internal/InternalDistributedSystemTest.java And these unit tests create a full Cache stack so they belong in src/integrationTest:* geode-lucene/src/test/java/org/apache/geode/cache/lucene/FlatFormatPdxSerializerJunitTest.java* geode-protobuf/src/test/java/org/apache/geode/internal/protocol/protobuf/v1/serialization/codec/JsonPdxConverterJUnitTest.java And one last unit test that I was able to fix -- this test creates a spy to test as a partial mock with a common goof that results in a full Cache being created and then not used by the test:* extensions/geode-modules/src/test/java/org/apache/geode/modules/util/BootstrappingFunctionTest.java 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 > Unit tests should not pollute the environment > - > > Key: GEODE-8032 > URL: https://issues.apache.org/jira/browse/GEODE-8032 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Unit tests should not pollute the environment. > From https://www.artima.com/weblogs/viewpost.jsp?thread=126923: > A test is not a unit test if: > * It talks to the database > * It communicates across the network > * It touches the file system > * It can't run at the same time as any of your other unit tests > * You have to do special things to your environment (such as editing config > files) to run it. > Tests that do these things are good but they should be an integration or > system test instead of a unit test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator
[ https://issues.apache.org/jira/browse/GEODE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-8031. Fix Version/s: 1.13.0 Resolution: Fixed > CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator > fails on Windows due to SSL not enabled for locator > - > > Key: GEODE-8031 > URL: https://issues.apache.org/jira/browse/GEODE-8031 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > > testNewSSLConfigSSLComponentLocator FAILED > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at > org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106) > This failure is possibly caused by previously run tests not closing the > static SocketCreatorFactory instance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7953) Create Restore Redundancy Internal API
[ https://issues.apache.org/jira/browse/GEODE-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094019#comment-17094019 ] ASF subversion and git services commented on GEODE-7953: Commit 6d358846566fd74ee85ecab311d2eeb004c44897 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d35884 ] GEODE-7953: Restore Redundancy Internal API (#5010) - Add RestoreRedundancyOperation interface and Impl class - Add RestoreRedundancyResults interface and Impl class - Add RegionRedundancyStatus interface and Impl class - Add accessor methods for RestoreRedundancyOperation to ResourceManager interface - Replace manually-synchronized sets in InternalResourceManager with ConcurrentHashMap - Add stats for restore redundancy operations - Add unit and DUnit tests for all the above This commit restores the changes originally introduced in 0f9918510b24f2169189936a92951b9bb4f313f1 and reverted in 9fad2c0fba51f1a8beb24c311255dfa55a537c99 Authored-by: Donal Evans > Create Restore Redundancy Internal API > -- > > Key: GEODE-7953 > URL: https://issues.apache.org/jira/browse/GEODE-7953 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.13.0 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Introduce an internal API to allow redundancy to be restored and primary > bucket hosts reassigned without necessitating a full rebalance. > As described in the RFC found here: > https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094041#comment-17094041 ] ASF GitHub Bot commented on GEODE-7971: --- boglesby commented on pull request #4928: URL: https://github.com/apache/geode/pull/4928#issuecomment-620307053 I ran a test with this scenario: - 2 colocated partitioned regions called customer and order attached to a parallel sender - 1 replicated region called customer_creation_time attached to a serial sender The transaction does: - put 1 customer into customer region - put 10 orders into order region - put customer create time into customer_creation_time region Here are some notes from this test: GatewaySenderFactoryImpl.configureGatewaySender needs a line like below. Otherwise, the Geode xml case doesn't pass the boolean to the sender. ``` this.attrs.isGroupTransactionEvents = senderCreation.isGroupTransactionEvents() ``` The scenario above is not supported since the transaction is spanning multiple senders. I don't think there is a way to determine that during configuration, but the message that is logged needs additional info: ``` [error 2020/04/27 15:45:57.439 PDT tid=0x57] Not all events in transaction go to the same senders that group transactions ``` At least the sender ids should be logged if not which events go to which senders. I see `TXLastEventInTransactionUtils.checkAllEventsGoToSameGroupingSenders` is throwing the ServiceConfigurationError. Maybe that ServiceConfigurationError's message can contain this info. Then you can log the error. Maybe even the actual stack. Also, I see that the test above succeeds. The batch is sent with the customer and orders. Other than that warning which the customer could easily miss, there is no evidence that all the events in the transaction were not sent in the same batch. Maybe the commit should fail? I'll change my test to remove the serial sender and continue to look at this. 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 > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.13.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands
[
https://issues.apache.org/jira/browse/GEODE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094059#comment-17094059
]
ASF GitHub Bot commented on GEODE-7954:
---
lgtm-com[bot] commented on pull request #5004:
URL: https://github.com/apache/geode/pull/5004#issuecomment-620315436
This pull request **introduces 2 alerts** when merging
4426e0621a2f3a3778fe0ec5432f13dd89614ac1 into
6d358846566fd74ee85ecab311d2eeb004c44897 - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-22aebb54a0f8dd3dc909416cc5650c3281d317ba)
**new alerts:**
* 2 for Cast from abstract to concrete collection
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 gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*]
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified
> partitioned regions and trigger the restore redundancy operation for those
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
> * Redundancy is fully satisfied for all regions that were included, either
> explicitly or implicitly.
> * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
> * At least one bucket in a region has zero redundant copies, and that region
> has redundancy configured.
> At least one bucket in a region has fewer than the configured number of
> redundant copies.
> * At least one of the explicitly included partitioned regions is not found.
> * There is a member in the system with a version of Geode older than 1.13.0
> (assuming that is the version in which this feature is implemented).
> * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command.
> If neither argument is specified, all regions will be included. Included
> regions will take precedence over excluded regions when both are specified.
> The restore redundancy command will also take an optional
> {{\-\-reassign-primaries}} argument to determine if primaries should be
> reassigned or not during the operation. The default behaviour will be to
> reassign primaries.
> Both commands will output a list of regions with zero redundant copies first
> (unless they are configured to have zero redundancy), then regions with less
> than their configured redundancy, then regions with full redundancy. The
> restore redundancy command will also output information about how many
> primaries were reassigned and how long that process took, similar to the
> existing rebalance command.
> As described here:
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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 ] Nabarun Nag updated GEODE-8029: --- Labels: GeodeCommons caching-applications (was: ) > 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 >Priority: Major > Labels: GeodeCommons, caching-applications > 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] [Commented] (GEODE-7702) DistributedAckRegionCCEDUnitTest > testClearOnNonReplicateWithConcurrentEvents is showing a product bug
[
https://issues.apache.org/jira/browse/GEODE-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094213#comment-17094213
]
ASF subversion and git services commented on GEODE-7702:
Commit b868cf60559b3d712018ac75eaabd13f011751f7 in geode's branch
refs/heads/feature/GEODE-7702 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b868cf6 ]
GEODE-7702: bulkOp from accessor or NORMAL should sync with clear
> DistributedAckRegionCCEDUnitTest >
> testClearOnNonReplicateWithConcurrentEvents is showing a product bug
> ---
>
> Key: GEODE-7702
> URL: https://issues.apache.org/jira/browse/GEODE-7702
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
>
> testClearOnNonReplicateWithConcurrentEvents in
> DistributedAckRegionCCEDUnitTest.java
> versionTestClearOnNonReplicateWithConcurrentEvents in
> MultiVMRegionTestCase.java
> doOpsLoop
> doOpsLoopNoFlush
> {noformat}
> case 5:
> if (includeClear) {
> CCRegion.clear();
> break;
> } else {
> if (CCRegion.getAttributes().getDataPolicy().withReplication()) {
> if (oldkey != null) {
> CCRegion.putIfAbsent(oldkey, value);
> }
> break;
> } // else fall through to invalidate
> } {noformat}
> the addition of this chunk of code causes this test to fail.
> The core of the problem is that a putall and a clear are happening
> concurrently and the "system" does not respond by either clearing all entries
> or letting all entries persist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7702) DistributedAckRegionCCEDUnitTest > testClearOnNonReplicateWithConcurrentEvents is showing a product bug
[
https://issues.apache.org/jira/browse/GEODE-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094212#comment-17094212
]
ASF GitHub Bot commented on GEODE-7702:
---
gesterzhou opened a new pull request #5012:
URL: https://github.com/apache/geode/pull/5012
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> DistributedAckRegionCCEDUnitTest >
> testClearOnNonReplicateWithConcurrentEvents is showing a product bug
> ---
>
> Key: GEODE-7702
> URL: https://issues.apache.org/jira/browse/GEODE-7702
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
>
> testClearOnNonReplicateWithConcurrentEvents in
> DistributedAckRegionCCEDUnitTest.java
> versionTestClearOnNonReplicateWithConcurrentEvents in
> MultiVMRegionTestCase.java
> doOpsLoop
> doOpsLoopNoFlush
> {noformat}
> case 5:
> if (includeClear) {
> CCRegion.clear();
> break;
> } else {
> if (CCRegion.getAttributes().getDataPolicy().withReplication()) {
> if (oldkey != null) {
> CCRegion.putIfAbsent(oldkey, value);
> }
> break;
> } // else fall through to invalidate
> } {noformat}
> the addition of this chunk of code causes this test to fail.
> The core of the problem is that a putall and a clear are happening
> concurrently and the "system" does not respond by either clearing all entries
> or letting all entries persist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
