[jira] [Assigned] (GEODE-8364) Change log level of C++ client at runtime
[ https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8364: --- Assignee: Alberto Bustamante Reyes > Change log level of C++ client at runtime > - > > Key: GEODE-8364 > URL: https://issues.apache.org/jira/browse/GEODE-8364 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > Currently it is not possible to change log level of the C++ after it is > created. > It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8364) Change log level of C++ client at runtime
Alberto Bustamante Reyes created GEODE-8364: --- Summary: Change log level of C++ client at runtime Key: GEODE-8364 URL: https://issues.apache.org/jira/browse/GEODE-8364 Project: Geode Issue Type: Improvement Components: native client Reporter: Alberto Bustamante Reyes Currently it is not possible to change log level of the C++ after it is created. It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[ https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159241#comment-17159241 ] ASF GitHub Bot commented on GEODE-8364: --- alb3rtobr opened a new pull request #629: URL: https://github.com/apache/geode-native/pull/629 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 log level of C++ client at runtime > - > > Key: GEODE-8364 > URL: https://issues.apache.org/jira/browse/GEODE-8364 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > Currently it is not possible to change log level of the C++ after it is > created. > It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8364) Change log level of C++ client at runtime
[ https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8364: -- Labels: pull-request-available (was: ) > Change log level of C++ client at runtime > - > > Key: GEODE-8364 > URL: https://issues.apache.org/jira/browse/GEODE-8364 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Currently it is not possible to change log level of the C++ after it is > created. > It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159265#comment-17159265 ] ASF GitHub Bot commented on GEODE-7670: --- jujoramos commented on pull request #4848: URL: https://github.com/apache/geode/pull/4848#issuecomment-659469073 @agingade @gesterzhou After changing the approach used to shutdown the members during the tests (`DistributionMessageObserver` instead of `CacheWriter`) there are no more failures related to the `Timeout during netsearch/netload/netwrite` I was seeing before, CI is fully green so this `PR` is ready to merge once you approve it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-7670: -- Labels: GeodeCommons pull-request-available (was: GeodeCommons) > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8364) Change log level of C++ client at runtime
[ https://issues.apache.org/jira/browse/GEODE-8364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159296#comment-17159296 ] ASF GitHub Bot commented on GEODE-8364: --- pdxcodemonkey commented on pull request #629: URL: https://github.com/apache/geode-native/pull/629#issuecomment-659489989 Do you have a use case for this? I don't suppose it's really harming anything, but I'm not sure I understand why/how you'd want to change this midstream, and it could cause problems down the road for things like log analysis tools. We've also been planning for a long time to completely replace our logging mechanism with an off-the-shelf solution like spdlog or log4cpp, and this would add a new logging feature that we'd have to replicate with any such change. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change log level of C++ client at runtime > - > > Key: GEODE-8364 > URL: https://issues.apache.org/jira/browse/GEODE-8364 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Currently it is not possible to change log level of the C++ after it is > created. > It will be useful to have a way to change it at runtime. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8331) allow GFSH to connect to newer and older locator/server.
[ https://issues.apache.org/jira/browse/GEODE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159309#comment-17159309 ] ASF GitHub Bot commented on GEODE-8331: --- jinmeiliao merged pull request #5375: URL: https://github.com/apache/geode/pull/5375 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 > allow GFSH to connect to newer and older locator/server. > > > Key: GEODE-8331 > URL: https://issues.apache.org/jira/browse/GEODE-8331 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When using an older or newer gfsh to connect to an older or newer distributed > system gfsh will throw a warning error and not connect. > Example warning message Cannot use a 9.8.5 gfsh client to connect to a 9.9.0 > cluster.. > The desired behavior is to allow gfsh connect and only if there is an issue > with an updated /unknown command parsing should the system throw an error and > provide the extra guidance of what version the servers are at and the version > of the current gfsh cli. > Initially add these capability into the newer product version > Later based on the feasibility of adding this to older version, this will be > ported into the older version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8331) allow GFSH to connect to newer and older locator/server.
[ https://issues.apache.org/jira/browse/GEODE-8331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159310#comment-17159310 ] ASF subversion and git services commented on GEODE-8331: Commit 0f16c0fe1b28a7f20d490b441a21ff942acd810b in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f16c0f ] GEODE-8331: allow GFSH to connect to other versions of cluster (#5375) > allow GFSH to connect to newer and older locator/server. > > > Key: GEODE-8331 > URL: https://issues.apache.org/jira/browse/GEODE-8331 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > When using an older or newer gfsh to connect to an older or newer distributed > system gfsh will throw a warning error and not connect. > Example warning message Cannot use a 9.8.5 gfsh client to connect to a 9.9.0 > cluster.. > The desired behavior is to allow gfsh connect and only if there is an issue > with an updated /unknown command parsing should the system throw an error and > provide the extra guidance of what version the servers are at and the version > of the current gfsh cli. > Initially add these capability into the newer product version > Later based on the feasibility of adding this to older version, this will be > ported into the older version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8298) member version comparison sense inconsistent when deciding on multicast
[
https://issues.apache.org/jira/browse/GEODE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159316#comment-17159316
]
ASF GitHub Bot commented on GEODE-8298:
---
Bill commented on a change in pull request #5370:
URL: https://github.com/apache/geode/pull/5370#discussion_r455891914
##
File path:
geode-membership/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberData.java
##
@@ -507,8 +507,8 @@ public void setVmKind(int vmKind) {
@Override
- public void setVersion(Version v) {
-setVersionOrdinal(v.ordinal());
+ public void setVersion(VersionOrdinal versionOrdinal) {
+setVersionOrdinal(versionOrdinal.ordinal());
Review comment:
Let's set `versionOrdinal` (object reference) directly here and
eliminate `MemberData.setVersionOrdinal(short)` entirely. The method shouldn't
exist at all. We should not be passing a `short` ordinal to a `MemberData`.
There are three places `MemberData.setVersionOrdinal(short)` is called:
1. here: just set the field directly
2. `readEssentialData()`: replace
`setVersionOrdinal(VersioningIO.readOrdinal(in));` with `setVersion(Versioning.
getVersionOrdinal(VersioningIO.readOrdinal(in)))`
3. `GMSMemberDataVersionJUnitTest.testSetVersionOrdinal()`: delete this test
method
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> member version comparison sense inconsistent when deciding on multicast
> ---
>
> Key: GEODE-8298
> URL: https://issues.apache.org/jira/browse/GEODE-8298
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: starter
>
> Since about 2014 when we introduced the {{Version}} class to replace use of
> {{short}} s all over the place for serialization versions, these two loops in
> {{GMSMembership.processView()}} have used comparisons that disagree in sense:
> {code}
> // We perform the update under a global lock so that other
> // incoming events will not be lost in terms of our global view.
> latestViewWriteLock.lock();
> try {
> // first determine the version for multicast message serialization
> VersionOrdinal version = Version.CURRENT;
> for (final Entry internalIDLongEntry : surpriseMembers
> .entrySet()) {
> ID mbr = internalIDLongEntry.getKey();
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && version.compareTo(itsVersion) < 0) {
> version = itsVersion;
> }
> }
> for (ID mbr : newView.getMembers()) {
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && itsVersion.compareTo(version) < 0) {
> version = mbr.getVersionObject();
> }
> }
> disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
> {code}
> The goal here is to find the oldest version and if that version is older than
> our local version we disable multicast. So we want to put the minimum into
> {{version}}. So the first loop's comparison is wrong and the second one is
> right.
> While we are in here let's combine the two loops using
> {{Stream.concat(surpriseMembers.entrySet().stream().map(entry->entry.getKey()),
> newView.getMembers().stream()).forEach(member -> ...)}}.
> Alternatives are described here:
> https://www.baeldung.com/java-combine-multiple-collections
> Once we have the combined {{Iterable}} we can use something like
> {{Collections.min()}} to find the minimum in one swell foop and this whole
> thing collapses to one or two declarative expressions.
> When this story is complete, the functionality will be in a separate method
> and we'll have a unit test for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8298) member version comparison sense inconsistent when deciding on multicast
[
https://issues.apache.org/jira/browse/GEODE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8298:
--
Labels: pull-request-available starter (was: starter)
> member version comparison sense inconsistent when deciding on multicast
> ---
>
> Key: GEODE-8298
> URL: https://issues.apache.org/jira/browse/GEODE-8298
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available, starter
>
> Since about 2014 when we introduced the {{Version}} class to replace use of
> {{short}} s all over the place for serialization versions, these two loops in
> {{GMSMembership.processView()}} have used comparisons that disagree in sense:
> {code}
> // We perform the update under a global lock so that other
> // incoming events will not be lost in terms of our global view.
> latestViewWriteLock.lock();
> try {
> // first determine the version for multicast message serialization
> VersionOrdinal version = Version.CURRENT;
> for (final Entry internalIDLongEntry : surpriseMembers
> .entrySet()) {
> ID mbr = internalIDLongEntry.getKey();
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && version.compareTo(itsVersion) < 0) {
> version = itsVersion;
> }
> }
> for (ID mbr : newView.getMembers()) {
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && itsVersion.compareTo(version) < 0) {
> version = mbr.getVersionObject();
> }
> }
> disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
> {code}
> The goal here is to find the oldest version and if that version is older than
> our local version we disable multicast. So we want to put the minimum into
> {{version}}. So the first loop's comparison is wrong and the second one is
> right.
> While we are in here let's combine the two loops using
> {{Stream.concat(surpriseMembers.entrySet().stream().map(entry->entry.getKey()),
> newView.getMembers().stream()).forEach(member -> ...)}}.
> Alternatives are described here:
> https://www.baeldung.com/java-combine-multiple-collections
> Once we have the combined {{Iterable}} we can use something like
> {{Collections.min()}} to find the minimum in one swell foop and this whole
> thing collapses to one or two declarative expressions.
> When this story is complete, the functionality will be in a separate method
> and we'll have a unit test for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8359) Server logs NPE as a warning while processing RegisterInterestList requests from clients during (server) shutdown
[
https://issues.apache.org/jira/browse/GEODE-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159342#comment-17159342
]
ASF GitHub Bot commented on GEODE-8359:
---
mhansonp commented on a change in pull request #5371:
URL: https://github.com/apache/geode/pull/5371#discussion_r455924506
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/RegisterInterestList66.java
##
@@ -163,29 +162,40 @@ public void cmdExecute(final Message clientMessage, final
ServerConnection serve
}
try {
securityService.authorize(Resource.DATA, Operation.READ, regionName);
- AuthorizeRequest authzRequest = serverConnection.getAuthzRequest();
- if (authzRequest != null) {
+ AuthorizeRequest authorizeRequest = serverConnection.getAuthzRequest();
+ if (authorizeRequest != null) {
if (!DynamicRegionFactory.regionIsDynamicRegionList(regionName)) {
RegisterInterestOperationContext registerContext =
- authzRequest.registerInterestListAuthorize(regionName, keys,
policy);
- keys = (List) registerContext.getKey();
+ authorizeRequest.registerInterestListAuthorize(regionName, keys,
policy);
+ keys = (List) registerContext.getKey();
}
}
// Register interest
serverConnection.getAcceptor().getCacheClientNotifier().registerClientInterest(regionName,
keys, serverConnection.getProxyID(), isDurable,
sendUpdatesAsInvalidates, true,
regionDataPolicyPartBytes[0], true);
-} catch (Exception ex) {
+} catch (Exception e) {
// If an interrupted exception is thrown , rethrow it
- checkForInterrupt(serverConnection, ex);
+ checkForInterrupt(serverConnection, e);
// Otherwise, write an exception message and continue
- writeChunkedException(clientMessage, ex, serverConnection);
+ writeChunkedException(clientMessage, e, serverConnection);
serverConnection.setAsTrue(RESPONDED);
return;
}
-boolean isPrimary = serverConnection.getAcceptor().getCacheClientNotifier()
-.getClientProxy(serverConnection.getProxyID()).isPrimary();
+CacheClientProxy ccp =
serverConnection.getAcceptor().getCacheClientNotifier()
+.getClientProxy(serverConnection.getProxyID());
+
+if (ccp == null) {
+ IOException ioException = new IOException(
+ "CacheClientProxy for this client is no longer on the server , so
registerInterest operation is unsuccessful");
Review comment:
done
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Server logs NPE as a warning while processing RegisterInterestList requests
> from clients during (server) shutdown
> -
>
> Key: GEODE-8359
> URL: https://issues.apache.org/jira/browse/GEODE-8359
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Getting a null pointer exception when RegisterinterestList is called during
> shutdown.
> {noformat}
> at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterestList66.cmdExecute(RegisterInterestList66.java:188)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.lang.Thread.run(Thread.java:748) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8365) Delta not propagating updated hash values properly
Sarah Abbey created GEODE-8365: -- Summary: Delta not propagating updated hash values properly Key: GEODE-8365 URL: https://issues.apache.org/jira/browse/GEODE-8365 Project: Geode Issue Type: Bug Components: redis Reporter: Sarah Abbey Delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8358) Run Geode Redis session tests against native Redis
[ https://issues.apache.org/jira/browse/GEODE-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159414#comment-17159414 ] ASF GitHub Bot commented on GEODE-8358: --- jdeppe-pivotal merged pull request #5373: URL: https://github.com/apache/geode/pull/5373 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 > Run Geode Redis session tests against native Redis > -- > > Key: GEODE-8358 > URL: https://issues.apache.org/jira/browse/GEODE-8358 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > > Ensure Spring Session works the same way with native Redis as it does with > Redis API for Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8358) Run Geode Redis session tests against native Redis
[ https://issues.apache.org/jira/browse/GEODE-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8358: -- Labels: pull-request-available (was: ) > Run Geode Redis session tests against native Redis > -- > > Key: GEODE-8358 > URL: https://issues.apache.org/jira/browse/GEODE-8358 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Ensure Spring Session works the same way with native Redis as it does with > Redis API for Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8365) Delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8365: -- Labels: pull-request-available (was: ) > Delta not propagating updated hash values properly > -- > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8365) Delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159416#comment-17159416 ] ASF GitHub Bot commented on GEODE-8365: --- sabbeyPivotal opened a new pull request #5377: URL: https://github.com/apache/geode/pull/5377 Delta not propagating updated hash values properly. 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 > Delta not propagating updated hash values properly > -- > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > > Delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8358) Run Geode Redis session tests against native Redis
[ https://issues.apache.org/jira/browse/GEODE-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159417#comment-17159417 ] ASF subversion and git services commented on GEODE-8358: Commit 86e3266962911c2914cdecd222418cdab87df62d in geode's branch refs/heads/develop from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=86e3266 ] GEODE-8358: Run Geode Redis session tests against native Redis (#5373) > Run Geode Redis session tests against native Redis > -- > > Key: GEODE-8358 > URL: https://issues.apache.org/jira/browse/GEODE-8358 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Ensure Spring Session works the same way with native Redis as it does with > Redis API for Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8358) Run Geode Redis session tests against native Redis
[ https://issues.apache.org/jira/browse/GEODE-8358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8358. Fix Version/s: 1.14.0 Resolution: Fixed > Run Geode Redis session tests against native Redis > -- > > Key: GEODE-8358 > URL: https://issues.apache.org/jira/browse/GEODE-8358 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Ensure Spring Session works the same way with native Redis as it does with > Redis API for Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8359) Server logs NPE as a warning while processing RegisterInterestList requests from clients during (server) shutdown
[
https://issues.apache.org/jira/browse/GEODE-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159464#comment-17159464
]
ASF subversion and git services commented on GEODE-8359:
Commit 85ab54130542e95e9324cac6af59a9eb80253bff in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ab541 ]
GEODE-8359 (#5371)
GEODE-8359: Code needed protection against the possibility of the null being
returned.
There was also a fair amount of inconsistency between files that are very
tightly related.
> Server logs NPE as a warning while processing RegisterInterestList requests
> from clients during (server) shutdown
> -
>
> Key: GEODE-8359
> URL: https://issues.apache.org/jira/browse/GEODE-8359
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Getting a null pointer exception when RegisterinterestList is called during
> shutdown.
> {noformat}
> at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterestList66.cmdExecute(RegisterInterestList66.java:188)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.lang.Thread.run(Thread.java:748) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8359) Server logs NPE as a warning while processing RegisterInterestList requests from clients during (server) shutdown
[
https://issues.apache.org/jira/browse/GEODE-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159461#comment-17159461
]
ASF GitHub Bot commented on GEODE-8359:
---
mhansonp merged pull request #5371:
URL: https://github.com/apache/geode/pull/5371
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
> Server logs NPE as a warning while processing RegisterInterestList requests
> from clients during (server) shutdown
> -
>
> Key: GEODE-8359
> URL: https://issues.apache.org/jira/browse/GEODE-8359
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Getting a null pointer exception when RegisterinterestList is called during
> shutdown.
> {noformat}
> at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterestList66.cmdExecute(RegisterInterestList66.java:188)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.lang.Thread.run(Thread.java:748) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8359) Server logs NPE as a warning while processing RegisterInterestList requests from clients during (server) shutdown
[
https://issues.apache.org/jira/browse/GEODE-8359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159463#comment-17159463
]
ASF subversion and git services commented on GEODE-8359:
Commit 85ab54130542e95e9324cac6af59a9eb80253bff in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=85ab541 ]
GEODE-8359 (#5371)
GEODE-8359: Code needed protection against the possibility of the null being
returned.
There was also a fair amount of inconsistency between files that are very
tightly related.
> Server logs NPE as a warning while processing RegisterInterestList requests
> from clients during (server) shutdown
> -
>
> Key: GEODE-8359
> URL: https://issues.apache.org/jira/browse/GEODE-8359
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mark Hanson
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Getting a null pointer exception when RegisterinterestList is called during
> shutdown.
> {noformat}
> at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterestList66.cmdExecute(RegisterInterestList66.java:188)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1181)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.lang.Thread.run(Thread.java:748) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8266) StatForNotQueuedConflated not incremented in time
[
https://issues.apache.org/jira/browse/GEODE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159466#comment-17159466
]
Mark Hanson commented on GEODE-8266:
Failed on Windows
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/342]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0224/test-results/test/1594929636/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0224/test-artifacts/1594929636/windows-unittestfiles-OpenJDK8-1.14.0-build.0224.tgz
> StatForNotQueuedConflated not incremented in time
> -
>
> Key: GEODE-8266
> URL: https://issues.apache.org/jira/browse/GEODE-8266
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/259#A
> {code}
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest
> >
> whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented
> FAILED
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest.whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented(ParallelGatewaySenderQueueJUnitTest.java:146)
> {code}
> It appears we are waiting 100ms for the statistic to be incremented. Perhaps
> we need to wait longer. Or maybe there is product bug here?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8365) Redis delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8365: --- Description: Redis delta not propagating updated hash values properly. (was: Delta not propagating updated hash values properly.) > Redis delta not propagating updated hash values properly > > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Redis delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8365) Redis delta not propagating updated hash values properly
[ https://issues.apache.org/jira/browse/GEODE-8365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8365: --- Summary: Redis delta not propagating updated hash values properly (was: Delta not propagating updated hash values properly) > Redis delta not propagating updated hash values properly > > > Key: GEODE-8365 > URL: https://issues.apache.org/jira/browse/GEODE-8365 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > Delta not propagating updated hash values properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
Barrett Oglesby created GEODE-8366:
--
Summary: A non-persistent partitioned region attached to a
non-persistent gateway sender throws an exception if its leader co-located
region is persistent
Key: GEODE-8366
URL: https://issues.apache.org/jira/browse/GEODE-8366
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
With this configuration:
{noformat}
{noformat}
An exception is thrown, and the Cache fails to start.
The error and exception are:
{noformat}
[error 2020/07/16 14:06:59.908 PDT tid=0x1]
org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
gateway sender non_persistent_sender can not be attached to persistent region
/persistent_parent
{noformat}
{noformat}
Exception in thread "main"
org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
gateway sender non_persistent_sender can not be attached to persistent region
/persistent_parent
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
at
org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
at
org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
{noformat}
The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
currently compares the data policy of the input region's leader region with the
sender's persistence policy. It assumes the input region and the leader region
have the same data policy. In this scenario, that is not the case. The input
region is 'non_persistent_child' which is not persistent, and the leader region
is 'persistent_parent' which is persistent. The sender is
'non_persistent_sender' which is not persistent. So, instead of comparing the
data policy of 'non_persistent_child' to the sender which would succeed since
they are both not persistent, it compares the data policy of
'persistent_parent' to the sender which fails since one is persistent, and the
other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
[
https://issues.apache.org/jira/browse/GEODE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-8366:
--
Assignee: Barrett Oglesby
> A non-persistent partitioned region attached to a non-persistent gateway
> sender throws an exception if its leader co-located region is persistent
> -
>
> Key: GEODE-8366
> URL: https://issues.apache.org/jira/browse/GEODE-8366
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> With this configuration:
> {noformat}
> enable-persistence="false" remote-distributed-system-id="1"/>
>
>
>
> redundant-copies="1"/>
>
>
> {noformat}
> An exception is thrown, and the Cache fails to start.
> The error and exception are:
> {noformat}
> [error 2020/07/16 14:06:59.908 PDT tid=0x1]
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> {noformat}
> {noformat}
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
> {noformat}
> The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
> currently compares the data policy of the input region's leader region with
> the sender's persistence policy. It assumes the input region and the leader
> region have the same data policy. In this scenario, that is not the case. The
> input region is 'non_persistent_child' which is not persistent, and the
> leader region is 'persistent_parent' which is persistent. The sender is
> 'non_persistent_sender' which is not persistent. So, instead of comparing the
> data policy of 'non_persistent_child' to the sender which would succeed since
> they are both not persistent, it compares the data policy of
> 'persistent_parent' to the sender which fails since one is persistent, and
> the other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
[
https://issues.apache.org/jira/browse/GEODE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159510#comment-17159510
]
ASF GitHub Bot commented on GEODE-8366:
---
boglesby opened a new pull request #5378:
URL: https://github.com/apache/geode/pull/5378
…eader region's to the sender
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
> A non-persistent partitioned region attached to a non-persistent gateway
> sender throws an exception if its leader co-located region is persistent
> -
>
> Key: GEODE-8366
> URL: https://issues.apache.org/jira/browse/GEODE-8366
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> With this configuration:
> {noformat}
> enable-persistence="false" remote-distributed-system-id="1"/>
>
>
>
> redundant-copies="1"/>
>
>
> {noformat}
> An exception is thrown, and the Cache fails to start.
> The error and exception are:
> {noformat}
> [error 2020/07/16 14:06:59.908 PDT tid=0x1]
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> {noformat}
> {noformat}
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
> {noformat}
> The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
> currently compares the data policy of the input region's leader region with
> the sender's persistence policy. It assumes the input region and the leader
> region have the same data policy. In this scenario, that is not the case. The
> input region is 'non_persistent_child' which is not persistent, and the
> leader region is 'persistent_parent' which is persistent. The sender is
> 'non_persistent_sender' which is not persistent. So, instead of comparing the
> data policy of 'non_persistent_child' to the sender which would succeed since
> they are both not persistent, it compares the data policy of
> 'persistent_parent' to the sender which fails since one is persistent, and
> the other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
[
https://issues.apache.org/jira/browse/GEODE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8366:
--
Labels: pull-request-available (was: )
> A non-persistent partitioned region attached to a non-persistent gateway
> sender throws an exception if its leader co-located region is persistent
> -
>
> Key: GEODE-8366
> URL: https://issues.apache.org/jira/browse/GEODE-8366
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> With this configuration:
> {noformat}
> enable-persistence="false" remote-distributed-system-id="1"/>
>
>
>
> redundant-copies="1"/>
>
>
> {noformat}
> An exception is thrown, and the Cache fails to start.
> The error and exception are:
> {noformat}
> [error 2020/07/16 14:06:59.908 PDT tid=0x1]
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> {noformat}
> {noformat}
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
> {noformat}
> The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
> currently compares the data policy of the input region's leader region with
> the sender's persistence policy. It assumes the input region and the leader
> region have the same data policy. In this scenario, that is not the case. The
> input region is 'non_persistent_child' which is not persistent, and the
> leader region is 'persistent_parent' which is persistent. The sender is
> 'non_persistent_sender' which is not persistent. So, instead of comparing the
> data policy of 'non_persistent_child' to the sender which would succeed since
> they are both not persistent, it compares the data policy of
> 'persistent_parent' to the sender which fails since one is persistent, and
> the other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
[
https://issues.apache.org/jira/browse/GEODE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159511#comment-17159511
]
ASF subversion and git services commented on GEODE-8366:
Commit cc53250ab8dc2451416ff3545dea9181fdb46667 in geode's branch
refs/heads/feature/GEODE-8366 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cc53250 ]
GEODE-8366: Compared the input region's data policy rather than the leader
region's to the sender
> A non-persistent partitioned region attached to a non-persistent gateway
> sender throws an exception if its leader co-located region is persistent
> -
>
> Key: GEODE-8366
> URL: https://issues.apache.org/jira/browse/GEODE-8366
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> With this configuration:
> {noformat}
> enable-persistence="false" remote-distributed-system-id="1"/>
>
>
>
> redundant-copies="1"/>
>
>
> {noformat}
> An exception is thrown, and the Cache fails to start.
> The error and exception are:
> {noformat}
> [error 2020/07/16 14:06:59.908 PDT tid=0x1]
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> {noformat}
> {noformat}
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
> {noformat}
> The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
> currently compares the data policy of the input region's leader region with
> the sender's persistence policy. It assumes the input region and the leader
> region have the same data policy. In this scenario, that is not the case. The
> input region is 'non_persistent_child' which is not persistent, and the
> leader region is 'persistent_parent' which is persistent. The sender is
> 'non_persistent_sender' which is not persistent. So, instead of comparing the
> data policy of 'non_persistent_child' to the sender which would succeed since
> they are both not persistent, it compares the data policy of
> 'persistent_parent' to the sender which fails since one is persistent, and
> the other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-8361:
--
Assignee: Donal Evans
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159521#comment-17159521
]
ASF GitHub Bot commented on GEODE-8361:
---
DonalEvans opened a new pull request #5379:
URL: https://github.com/apache/geode/pull/5379
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
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8361:
--
Labels: pull-request-available (was: )
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159529#comment-17159529
]
ASF GitHub Bot commented on GEODE-8361:
---
lgtm-com[bot] commented on pull request #5379:
URL: https://github.com/apache/geode/pull/5379#issuecomment-659712994
This pull request **introduces 1 alert** when merging
79f77d16c0239d092436a4e38b647dd206873c07 into
edaf14896d951554d406bd16969948bbd3953d38 - [view on
LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-af62e67a74b65d03080b5b1d99c2cbe2d4c7aa65)
**new alerts:**
* 1 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
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8316) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
[
https://issues.apache.org/jira/browse/GEODE-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou updated GEODE-8316:
-
Labels: CI (was: )
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
> ---
>
> Key: GEODE-8316
> URL: https://issues.apache.org/jira/browse/GEODE-8316
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
> Labels: CI
>
> {noformat}
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.10.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.11.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.12.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8367) Stopped parallel gateway sender still adds events into tmpDroppedEvents
Xiaojian Zhou created GEODE-8367: Summary: Stopped parallel gateway sender still adds events into tmpDroppedEvents Key: GEODE-8367 URL: https://issues.apache.org/jira/browse/GEODE-8367 Project: Geode Issue Type: Improvement Reporter: Xiaojian Zhou In GEODE-4942, we introduced tmpDroppedEvents to save the in-coming events when the parallel gateway sender is restarting. However, we did not consider the case that the sender could be purposely stopped. Even for the stopped sender, the events are continuously saved into tmpDroppedEvents, which used a lot of memory. We should determine if the sender is in the middle of restarting or purposely stopped. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159554#comment-17159554
]
ASF GitHub Bot commented on GEODE-8361:
---
agingade commented on a change in pull request #5379:
URL: https://github.com/apache/geode/pull/5379#discussion_r456132028
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionClear.java
##
@@ -401,7 +395,7 @@ protected void
handleClearFromDepartedMember(InternalDistributedMember departedM
}
}
- class LockForListenerAndClientNotification {
+ static class LockForListenerAndClientNotification {
Review comment:
Any reason for changing it to static? The PRClear is separate for each
PR.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159557#comment-17159557
]
ASF GitHub Bot commented on GEODE-8361:
---
DonalEvans commented on a change in pull request #5379:
URL: https://github.com/apache/geode/pull/5379#discussion_r456132648
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionClear.java
##
@@ -401,7 +395,7 @@ protected void
handleClearFromDepartedMember(InternalDistributedMember departedM
}
}
- class LockForListenerAndClientNotification {
+ static class LockForListenerAndClientNotification {
Review comment:
This was just a suggestion from the IDE. I'm happy to change it back if
it's better to do so.
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
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8361) Incorrect Bucket Count Warning Message Shown
[
https://issues.apache.org/jira/browse/GEODE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159566#comment-17159566
]
ASF GitHub Bot commented on GEODE-8361:
---
agingade commented on a change in pull request #5379:
URL: https://github.com/apache/geode/pull/5379#discussion_r456142819
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionClear.java
##
@@ -401,7 +395,7 @@ protected void
handleClearFromDepartedMember(InternalDistributedMember departedM
}
}
- class LockForListenerAndClientNotification {
+ static class LockForListenerAndClientNotification {
Review comment:
It should not be static.
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
> Incorrect Bucket Count Warning Message Shown
>
>
> Key: GEODE-8361
> URL: https://issues.apache.org/jira/browse/GEODE-8361
> Project: Geode
> Issue Type: Sub-task
> Components: logging
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Trivial
> Labels: pull-request-available
>
> While analysing some failures related to GEODE-7670, I've noticed that
> sometimes we report an incorrect bucket count within the warning message
> logged when the clear didn't complete successfully that could confuse our
> users.
> For this test the partition region always has 13 buckets so, as I user, I
> would never expect to see a bucket count higher than 13 in my logs (no matter
> how many redundant copies I have).
> ---
> Below are some examples:
> {noformat}
> [vm1] [warn 2020/07/15 11:56:17.739 GMT Connection(5)-172.17.0.5> tid=0x5f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 26
> [vm1] [warn 2020/07/15 11:57:48.403 GMT Connection(6)-172.17.0.9> tid=0x10f] Unable to clear all the buckets from
> the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 14
> [vm0] [warn 2020/07/15 12:07:36.227 GMT Connection(32)-172.17.0.25> tid=0x1fe] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 19
> [vm0] [warn 2020/07/15 12:08:56.277 GMT Connection(37)-172.17.0.24> tid=0x2a2] Unable to clear all the buckets
> from the partitioned region PartitionedRegion, either data (buckets) moved or
> member departed. expected to clear number of buckets: 13 actual cleared: 16
> {noformat}
> The full set of artefacts and results:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-results/repeatTest/1594816968/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-4848/test-artifacts/1594816968/stressnewtestfiles-geode-pr-4848.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8367) Stopped parallel gateway sender still adds events into tmpDroppedEvents
[ https://issues.apache.org/jira/browse/GEODE-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8367: -- Labels: pull-request-available (was: ) > Stopped parallel gateway sender still adds events into tmpDroppedEvents > --- > > Key: GEODE-8367 > URL: https://issues.apache.org/jira/browse/GEODE-8367 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > In GEODE-4942, we introduced tmpDroppedEvents to save the in-coming events > when the parallel gateway sender is restarting. However, we did not consider > the case that the sender could be purposely stopped. > Even for the stopped sender, the events are continuously saved into > tmpDroppedEvents, which used a lot of memory. > We should determine if the sender is in the middle of restarting or purposely > stopped. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8367) Stopped parallel gateway sender still adds events into tmpDroppedEvents
[ https://issues.apache.org/jira/browse/GEODE-8367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159645#comment-17159645 ] ASF GitHub Bot commented on GEODE-8367: --- gesterzhou opened a new pull request #5381: URL: https://github.com/apache/geode/pull/5381 …o tmpDroppedEvents 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 > Stopped parallel gateway sender still adds events into tmpDroppedEvents > --- > > Key: GEODE-8367 > URL: https://issues.apache.org/jira/browse/GEODE-8367 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > > In GEODE-4942, we introduced tmpDroppedEvents to save the in-coming events > when the parallel gateway sender is restarting. However, we did not consider > the case that the sender could be purposely stopped. > Even for the stopped sender, the events are continuously saved into > tmpDroppedEvents, which used a lot of memory. > We should determine if the sender is in the middle of restarting or purposely > stopped. -- This message was sent by Atlassian Jira (v8.3.4#803005)
