[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089570#comment-17089570
]
Juan Ramos commented on GEODE-6222:
---
Failed again for an unrelated PR ->
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/DistributedTestOpenJDK11/builds/7370.
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock 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.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8002) Refactor: Extract class for concurrency testing
[ https://issues.apache.org/jira/browse/GEODE-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089659#comment-17089659 ] ASF subversion and git services commented on GEODE-8002: Commit 7dbd9705970db2fe07bff8d21ed4bd0dc00fa8b0 in geode's branch refs/heads/develop from Murtuza Boxwala [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7dbd970 ] GEODE-8002: Extract common concurrent execution test code into LoopingThreads class (#4973) > Refactor: Extract class for concurrency testing > --- > > Key: GEODE-8002 > URL: https://issues.apache.org/jira/browse/GEODE-8002 > Project: Geode > Issue Type: Improvement > Components: redis, tests >Reporter: Murtuza Boxwala >Priority: Minor > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7994) Refactor Native Redis Acceptance Tests
[ https://issues.apache.org/jira/browse/GEODE-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089664#comment-17089664 ] ASF subversion and git services commented on GEODE-7994: Commit 33a890e73803618ceb05897ae3de443243c49ae1 in geode's branch refs/heads/develop from Murtuza Boxwala [ https://gitbox.apache.org/repos/asf?p=geode.git;h=33a890e ] GEODE-7994: Refactor naming for Native Redis Acceptance Tests (#4964) > Refactor Native Redis Acceptance Tests > -- > > Key: GEODE-7994 > URL: https://issues.apache.org/jira/browse/GEODE-7994 > Project: Geode > Issue Type: Improvement > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Rename Native Redis Acceptance tests and ensure all Jedis clients are closed > in tearDown method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7676) All expiration tasks are cleared after a Partitioned Region is cleared
[ https://issues.apache.org/jira/browse/GEODE-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089669#comment-17089669 ] ASF subversion and git services commented on GEODE-7676: Commit e87b3b7ab7cb48d2a4be9b114443dda56bfd9d70 in geode's branch refs/heads/feature/GEODE-7665 from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e87b3b7 ] GEODE-7676: Add PR clear with expiration tests (#4970) Added distributed tests to verify the clear operation on Partitioned Regions works as expected when expiration is configured. - Added unit and distributed tests. - Fixed LocalRegion class to clear the entryExpiryTasks Map whenever the cancelAllEntryExpiryTasks method is invoked. > All expiration tasks are cleared after a Partitioned Region is cleared > -- > > Key: GEODE-7676 > URL: https://issues.apache.org/jira/browse/GEODE-7676 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 50m > Remaining Estimate: 0h > > Clear operations are successful and all the expiration tasks are cleared in > the bucket level > Acceptance : > * DUnit tests ensuring that clear operations are successful > * Expiration tasks are cleared. > * 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] [Resolved] (GEODE-7676) All expiration tasks are cleared after a Partitioned Region is cleared
[ https://issues.apache.org/jira/browse/GEODE-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-7676. --- Fix Version/s: 1.13.0 Resolution: Fixed > All expiration tasks are cleared after a Partitioned Region is cleared > -- > > Key: GEODE-7676 > URL: https://issues.apache.org/jira/browse/GEODE-7676 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Fix For: 1.13.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Clear operations are successful and all the expiration tasks are cleared in > the bucket level > Acceptance : > * DUnit tests ensuring that clear operations are successful > * Expiration tasks are cleared. > * 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-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8006: - Summary: .asf.yaml notifications (was: Testing .asf.yaml notifications) > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8011) Split SetsIntegrationTest into multiple files
Murtuza Boxwala created GEODE-8011: -- Summary: Split SetsIntegrationTest into multiple files Key: GEODE-8011 URL: https://issues.apache.org/jira/browse/GEODE-8011 Project: Geode Issue Type: Improvement Components: redis, tests Reporter: Murtuza Boxwala For maintainability -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089783#comment-17089783 ] ASF subversion and git services commented on GEODE-8006: Commit 55c14ad43ade5c935651d3d868753ba75c7e4646 in geode-benchmarks's branch refs/heads/develop from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=55c14ad ] GEODE-8006 Add .asf.yaml to control notifications > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089784#comment-17089784 ] ASF subversion and git services commented on GEODE-8006: Commit 38114cea6c7d2363d282a46ea0724eee8b6a54e1 in geode-benchmarks's branch refs/heads/master from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=38114ce ] GEODE-8006 Add .asf.yaml to control notifications (cherry picked from commit 55c14ad43ade5c935651d3d868753ba75c7e4646) > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089793#comment-17089793 ] ASF subversion and git services commented on GEODE-8006: Commit 935e6ac27c8f8731a108ca88cc28776def6b33ee in geode-kafka-connector's branch refs/heads/master from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-kafka-connector.git;h=935e6ac ] GEODE-8006 Add .asf.yaml to control notifications > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089794#comment-17089794 ] ASF subversion and git services commented on GEODE-8006: Commit 4ac143b3e601f259b5c1b53dba3ce9f46da2eea4 in geode-native's branch refs/heads/develop from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=4ac143b ] GEODE-8006 Add .asf.yaml to control notifications > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089795#comment-17089795 ] ASF subversion and git services commented on GEODE-8006: Commit 24a7ce655055791d6b766b47424bf46429136334 in geode-native's branch refs/heads/master from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=24a7ce6 ] GEODE-8006 Add .asf.yaml to control notifications (cherry picked from commit 4ac143b3e601f259b5c1b53dba3ce9f46da2eea4) > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089797#comment-17089797 ] ASF subversion and git services commented on GEODE-8006: Commit b7abe28d0c71f60d07786789c5a0867a53b39f73 in geode-site's branch refs/heads/master from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=b7abe28 ] GEODE-8006 Add .asf.yaml to control notifications > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089804#comment-17089804 ] ASF subversion and git services commented on GEODE-8006: Commit 87e17289860a4add30c81d226158020bd2d4900a in geode's branch refs/heads/master from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode.git;h=87e1728 ] GEODE-8006 Add .asf.yaml to control notifications > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Please ignore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [geode] jujoramos commented on issue #4978: Fix for regression introduced by GEODE-7565
jujoramos commented on issue #4978: URL: https://github.com/apache/geode/pull/4978#issuecomment-617866275 @alb3rtobr: Yes, I've added several logging messages to trace the `PING` message from start to finish, unfortunately I've been having some infrastructure issues the whole day and wasn't able to run the tests again with the logging changes. Hopefully will have something to share tomorrow. 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
[jira] [Updated] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8006: - Description: Adding .asf.yaml files to control notifications from GitHub. See INFRA-20156. (was: Please ignore.) > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Adding .asf.yaml files to control notifications from GitHub. See INFRA-20156. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8010) Redis is too verbose in its logging
[ https://issues.apache.org/jira/browse/GEODE-8010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8010. - Fix Version/s: 1.13.0 Resolution: Fixed > Redis is too verbose in its logging > --- > > Key: GEODE-8010 > URL: https://issues.apache.org/jira/browse/GEODE-8010 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Every Redis command executed logs an info message containing "Executing Redis > command:". This is too verbose for info level. It will also impact > performance. Instead of "info" this message should be "debug". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8010) Redis is too verbose in its logging
[ https://issues.apache.org/jira/browse/GEODE-8010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089819#comment-17089819 ] ASF subversion and git services commented on GEODE-8010: Commit 471f49e1cfe0591077a53f5418f7355fe46e5528 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=471f49e ] GEODE-8010: change redis log message from info to debug (#4983) > Redis is too verbose in its logging > --- > > Key: GEODE-8010 > URL: https://issues.apache.org/jira/browse/GEODE-8010 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Every Redis command executed logs an info message containing "Executing Redis > command:". This is too verbose for info level. It will also impact > performance. Instead of "info" this message should be "debug". -- 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=17089821#comment-17089821 ] ASF subversion and git services commented on GEODE-7981: Commit d6c8c8c5f269aba9d424136c92b88d285ec6d5b2 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6c8c8c ] GEODE-7981: have redis default to PARTITION_REDUNDANT (#4981) Updated docs with no default. Also if the system property it set to an unknown shortcut then it now defaults to PARTITION_REDUNDANT instead of PARTITION. The test now validates this case and now uses assertThat instead of assert. > 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-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-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089838#comment-17089838 ] ASF subversion and git services commented on GEODE-8006: Commit 9b1d65264b44e426857c1934c5af4c250c86ff13 in geode's branch refs/heads/develop from Anthony Baker [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9b1d652 ] GEODE-8006 Add .asf.yaml to control notifications (cherry picked from commit 87e17289860a4add30c81d226158020bd2d4900a) > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Adding .asf.yaml files to control notifications from GitHub. See INFRA-20156. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-8006. -- Fix Version/s: 1.13.0 Resolution: Fixed > .asf.yaml notifications > --- > > Key: GEODE-8006 > URL: https://issues.apache.org/jira/browse/GEODE-8006 > Project: Geode > Issue Type: Task >Reporter: Anthony Baker >Priority: Major > Fix For: 1.13.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Adding .asf.yaml files to control notifications from GitHub. See INFRA-20156. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [geode] kirklund commented on issue #4963: GEODE-7503: Block Cache.close() until everything is disconnected
kirklund commented on issue #4963:
URL: https://github.com/apache/geode/pull/4963#issuecomment-617886184
@upthewaterspout, I have some questions about your review of Cache.close()
changes.
{noformat}
@Override
public void close(String reason, Throwable systemFailureCause, boolean
keepAlive,
boolean keepDS, boolean skipAwait) {
securityService.close();
if (isClosed()) {
if (!skipAwait &&
!Thread.currentThread().equals(CLOSING_THREAD.get())) {
waitUntilClosed();
}
return;
}
if (!keepDS && systemFailureCause == null
&& (isReconnecting() || system.getReconnectedSystem() != null)) {
logger.debug(
"Cache is shutting down distributed system connection.
isReconnecting={} reconnectedSystem={} keepAlive={} keepDS={}",
isReconnecting(), system.getReconnectedSystem(), keepAlive,
keepDS);
system.stopReconnectingNoDisconnect();
if (system.getReconnectedSystem() != null) {
system.getReconnectedSystem().disconnect();
}
return;
}
synchronized (GemFireCacheImpl.class) {
// ALL CODE FOR CLOSE SHOULD NOW BE UNDER STATIC SYNCHRONIZATION OF
GemFireCacheImpl.class
// static synchronization is necessary due to static resources
if (isClosed()) {
if (!skipAwait &&
!Thread.currentThread().equals(CLOSING_THREAD.get())) {
waitUntilClosed();
}
return;
}
CLOSING_THREAD.set(Thread.currentThread());
{noformat}
If I remove that 1st early-out, then all subsequent calls will repeatedly
execute the block about the reconnecting system. I’ve read the code that it
invokes — such as
{noformat}
system.stopReconnectingNoDisconnect();
{noformat}
and
{noformat}
system.getReconnectedSystem().disconnect()
{noformat}
… so far, I’m not convinced that it’s safe to remove the 1st early out. Are
you sure it’s safe to invoke these calls more than once? The current behavior
never invokes them more than once.
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
[GitHub] [geode] kirklund edited a comment on issue #4963: GEODE-7503: Block Cache.close() until everything is disconnected
kirklund edited a comment on issue #4963:
URL: https://github.com/apache/geode/pull/4963#issuecomment-617886184
@upthewaterspout, I have some questions about your review of Cache.close()
changes.
```
@Override
public void close(String reason, Throwable systemFailureCause, boolean
keepAlive,
boolean keepDS, boolean skipAwait) {
securityService.close();
if (isClosed()) {
if (!skipAwait &&
!Thread.currentThread().equals(CLOSING_THREAD.get())) {
waitUntilClosed();
}
return;
}
if (!keepDS && systemFailureCause == null
&& (isReconnecting() || system.getReconnectedSystem() != null)) {
logger.debug(
"Cache is shutting down distributed system connection.
isReconnecting={} reconnectedSystem={} keepAlive={} keepDS={}",
isReconnecting(), system.getReconnectedSystem(), keepAlive,
keepDS);
system.stopReconnectingNoDisconnect();
if (system.getReconnectedSystem() != null) {
system.getReconnectedSystem().disconnect();
}
return;
}
synchronized (GemFireCacheImpl.class) {
// ALL CODE FOR CLOSE SHOULD NOW BE UNDER STATIC SYNCHRONIZATION OF
GemFireCacheImpl.class
// static synchronization is necessary due to static resources
if (isClosed()) {
if (!skipAwait &&
!Thread.currentThread().equals(CLOSING_THREAD.get())) {
waitUntilClosed();
}
return;
}
CLOSING_THREAD.set(Thread.currentThread());
```
If I remove that 1st early-out, then all subsequent calls will repeatedly
execute the block about the reconnecting system. I’ve read the code that it
invokes — such as
```
system.stopReconnectingNoDisconnect();
```
and
```
system.getReconnectedSystem().disconnect()
```
… so far, I’m not convinced that it’s safe to remove the 1st early out. Are
you sure it’s safe to invoke these calls more than once? The current behavior
never invokes them more than once.
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
[GitHub] [geode] upthewaterspout edited a comment on issue #4963: GEODE-7503: Block Cache.close() until everything is disconnected
upthewaterspout edited a comment on issue #4963:
URL: https://github.com/apache/geode/pull/4963#issuecomment-617442287
The combination of a `ThreadLocal`, a `CountDownLatch`, and
`synchronized()` seems a bit complicated.
The whole close block is already inside of
`synchronized(GemFireCacheImpl.class) {}`. It seems like the race condition is
just with the early out at the beginning of close:
```
if (isClosed()) {
return;
}
```
Couldn't that just be changed to
```
if (skipWait && isClosed()) {
return;
}
```
To handle thread reentering cache.close, just don't add a skipWait check
inside the synchronized block here:
```
synchronized (GemFireCacheImpl.class) {
// ALL CODE FOR CLOSE SHOULD NOW BE UNDER STATIC SYNCHRONIZATION OF
GemFireCacheImpl.class
// static synchronization is necessary due to static resources
if (isClosed()) {
> Remove the below check
if (!skipAwait...)
```
Any code that gets into the synchronized block is guaranteed that either (a)
the cache has not been closed by another thread (b) the cache is completely
closed already or (c) the thread is reentering cache close, in which case it
should early out.
There is probably some wrinkle that I'm missing 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
[jira] [Commented] (GEODE-7957) Serializing and deserializing a CumulativeNonDistinctResults containing Structs fails with either an OutOfMemoryError or an IllegalArgumentException
[
https://issues.apache.org/jira/browse/GEODE-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089845#comment-17089845
]
ASF subversion and git services commented on GEODE-7957:
Commit 1ddd7de1d9b6c7c37f14db06f98acb769bd99b68 in geode's branch
refs/heads/develop from Jason Huynh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1ddd7de ]
GEODE-7957: query results toData will write to correct output stream (#4922)
* Previously, when a query is executed in a function, the toData on specific
results
set types would write directly to the wrong output stream, causing
deserialization issues
> Serializing and deserializing a CumulativeNonDistinctResults containing
> Structs fails with either an OutOfMemoryError or an IllegalArgumentException
>
>
> Key: GEODE-7957
> URL: https://issues.apache.org/jira/browse/GEODE-7957
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Barrett Oglesby
>Assignee: Jason Huynh
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Executing a query like:
> {noformat}
> SELECT pnl.TM_ID, pnl.PTD_ACCRETION_INV_AMT, pnl.FIRM_ACCT_ID, pnl.INSM_ID,
> adj.PL_POSN_ID , adj.DLY_ACCRETION_INV_AMT FROM /PnLPosition4 pnl ,
> /AdjustmentPosition4 adj where adj.PL_POSN_ID = pnl.PL_POSN_ID
> {noformat}
> Using a function that does:
> {noformat}
> QueryService queryService = CacheFactory.getAnyInstance().getQueryService();
> Query query = queryService.newQuery(queryStr);
> SelectResults results = (SelectResults) query.execute(rfc);
> context.getResultSender().lastResult(results);
> {noformat}
> Causes one of two exceptions when the CumulativeNonDistinctResults is
> deserialized.
> Either an IllegalArgumentException on the client like:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: unexpected typeCode: 46
> at
> org.apache.geode.internal.serialization.StaticSerialization.decodePrimitiveClass(StaticSerialization.java:502)
> at
> org.apache.geode.DataSerializer.readObjectArray(DataSerializer.java:1744)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:293)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> {noformat}
> Or an OutOfMemoryError on the server like:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.ArrayList.(ArrayList.java:152)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:289)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2508)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> {noformat}
> CumulativeNonDistinctResults.toData does:
> {noformat}
> HeapDataOutputStream hdos = new HeapDataOutputStream(1024, null);
> LongUpdater lu = hdos.reserveLong();
> ...
> DataSerializer.writeObjectArray(fields, out);
> ...
> lu.update(numElements);
> {noformat}
> NWayMergeResults.toData is broken in the same way
> The fix is to write the fields to hdos instead of out like:
> {noformat}
> DataSerializer.writeObjectArray(fields, hdos);
> {noformat}
> A work-around in the function is to convert the CumulativeNonDistinctResults
> to a List like:
> {noformat}
> context.getResultSender().lastResult(results.asList());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-8009) CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported protocol scheme
[
https://issues.apache.org/jira/browse/GEODE-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols reopened GEODE-8009:
-
> CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported
> protocol scheme
> --
>
> Key: GEODE-8009
> URL: https://issues.apache.org/jira/browse/GEODE-8009
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Barrett Oglesby
>Priority: Major
>
> The tanzu-gemfire-management-cf-plugin in both
> test-cloudcache-management-cf-pcc-1.10 and
> test-cloudcache-management-cf-pcc-1.11 is failing with unsupported protocol
> scheme.
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.11/builds/9
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.10/builds/11
> The plugin-test in both is show logging like:
> {noformat}
> Plugin gemfire 1.0.5 successfully installed.
> + cf='cf gemfire test'
> + ci/smoke-test.bash
> + service_instance_name=test
> + cf gemfire test commands
> Unable to reach 45201/management/. Error: Get "45201/management/":
> unsupported protocol scheme ""
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8009) CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported protocol scheme
[
https://issues.apache.org/jira/browse/GEODE-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089855#comment-17089855
]
Owen Nichols commented on GEODE-8009:
-
this does not appear to be a Geode bug. this repo does not belong to the
Apache Geode project.
> CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported
> protocol scheme
> --
>
> Key: GEODE-8009
> URL: https://issues.apache.org/jira/browse/GEODE-8009
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Barrett Oglesby
>Priority: Major
> Fix For: 1.12.1
>
>
> The tanzu-gemfire-management-cf-plugin in both
> test-cloudcache-management-cf-pcc-1.10 and
> test-cloudcache-management-cf-pcc-1.11 is failing with unsupported protocol
> scheme.
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.11/builds/9
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.10/builds/11
> The plugin-test in both is show logging like:
> {noformat}
> Plugin gemfire 1.0.5 successfully installed.
> + cf='cf gemfire test'
> + ci/smoke-test.bash
> + service_instance_name=test
> + cf gemfire test commands
> Unable to reach 45201/management/. Error: Get "45201/management/":
> unsupported protocol scheme ""
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8009) CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported protocol scheme
[
https://issues.apache.org/jira/browse/GEODE-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8009:
Fix Version/s: (was: 1.12.1)
> CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported
> protocol scheme
> --
>
> Key: GEODE-8009
> URL: https://issues.apache.org/jira/browse/GEODE-8009
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Barrett Oglesby
>Priority: Major
>
> The tanzu-gemfire-management-cf-plugin in both
> test-cloudcache-management-cf-pcc-1.10 and
> test-cloudcache-management-cf-pcc-1.11 is failing with unsupported protocol
> scheme.
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.11/builds/9
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.10/builds/11
> The plugin-test in both is show logging like:
> {noformat}
> Plugin gemfire 1.0.5 successfully installed.
> + cf='cf gemfire test'
> + ci/smoke-test.bash
> + service_instance_name=test
> + cf gemfire test commands
> Unable to reach 45201/management/. Error: Get "45201/management/":
> unsupported protocol scheme ""
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8009) CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported protocol scheme
[
https://issues.apache.org/jira/browse/GEODE-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-8009.
-
Resolution: Invalid
> CI failure: tanzu-gemfire-management-cf-plugin is failing with unsupported
> protocol scheme
> --
>
> Key: GEODE-8009
> URL: https://issues.apache.org/jira/browse/GEODE-8009
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Barrett Oglesby
>Priority: Major
>
> The tanzu-gemfire-management-cf-plugin in both
> test-cloudcache-management-cf-pcc-1.10 and
> test-cloudcache-management-cf-pcc-1.11 is failing with unsupported protocol
> scheme.
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.11/builds/9
> https://concourse.gemfire-ci.info/teams/main/pipelines/tanzu-gemfire-management-cf-plugin/jobs/test-cloudcache-management-cf-pcc-1.10/builds/11
> The plugin-test in both is show logging like:
> {noformat}
> Plugin gemfire 1.0.5 successfully installed.
> + cf='cf gemfire test'
> + ci/smoke-test.bash
> + service_instance_name=test
> + cf gemfire test commands
> Unable to reach 45201/management/. Error: Get "45201/management/":
> unsupported protocol scheme ""
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7957) Serializing and deserializing a CumulativeNonDistinctResults containing Structs fails with either an OutOfMemoryError or an IllegalArgumentException
[
https://issues.apache.org/jira/browse/GEODE-7957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh resolved GEODE-7957.
Fix Version/s: 1.13.0
Resolution: Fixed
> Serializing and deserializing a CumulativeNonDistinctResults containing
> Structs fails with either an OutOfMemoryError or an IllegalArgumentException
>
>
> Key: GEODE-7957
> URL: https://issues.apache.org/jira/browse/GEODE-7957
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.12.0
>Reporter: Barrett Oglesby
>Assignee: Jason Huynh
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.13.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Executing a query like:
> {noformat}
> SELECT pnl.TM_ID, pnl.PTD_ACCRETION_INV_AMT, pnl.FIRM_ACCT_ID, pnl.INSM_ID,
> adj.PL_POSN_ID , adj.DLY_ACCRETION_INV_AMT FROM /PnLPosition4 pnl ,
> /AdjustmentPosition4 adj where adj.PL_POSN_ID = pnl.PL_POSN_ID
> {noformat}
> Using a function that does:
> {noformat}
> QueryService queryService = CacheFactory.getAnyInstance().getQueryService();
> Query query = queryService.newQuery(queryStr);
> SelectResults results = (SelectResults) query.execute(rfc);
> context.getResultSender().lastResult(results);
> {noformat}
> Causes one of two exceptions when the CumulativeNonDistinctResults is
> deserialized.
> Either an IllegalArgumentException on the client like:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: unexpected typeCode: 46
> at
> org.apache.geode.internal.serialization.StaticSerialization.decodePrimitiveClass(StaticSerialization.java:502)
> at
> org.apache.geode.DataSerializer.readObjectArray(DataSerializer.java:1744)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:293)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> {noformat}
> Or an OutOfMemoryError on the server like:
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.ArrayList.(ArrayList.java:152)
> at
> org.apache.geode.cache.query.internal.CumulativeNonDistinctResults.fromData(CumulativeNonDistinctResults.java:289)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:332)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:383)
> at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2508)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> {noformat}
> CumulativeNonDistinctResults.toData does:
> {noformat}
> HeapDataOutputStream hdos = new HeapDataOutputStream(1024, null);
> LongUpdater lu = hdos.reserveLong();
> ...
> DataSerializer.writeObjectArray(fields, out);
> ...
> lu.update(numElements);
> {noformat}
> NWayMergeResults.toData is broken in the same way
> The fix is to write the fields to hdos instead of out like:
> {noformat}
> DataSerializer.writeObjectArray(fields, hdos);
> {noformat}
> A work-around in the function is to convert the CumulativeNonDistinctResults
> to a List like:
> {noformat}
> context.getResultSender().lastResult(results.asList());
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089882#comment-17089882
]
Ivan Godwin commented on GEODE-5782:
CI failure:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/77
{code:java}
org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
java.lang.AssertionError:
Expecting:
<(1053347840,1053376512)>
to match 'committed virtual memory size]' predicate.
at
org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:128)
{code}
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> 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.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7935) CI Failure: GridAdvisorDUnitTest.test2by2usingGroups
[
https://issues.apache.org/jira/browse/GEODE-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089896#comment-17089896
]
ASF subversion and git services commented on GEODE-7935:
Commit 65dd63e2b4c05f180e40e94afc94b51d2ac57626 in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=65dd63e ]
GEODE-7935: Awaiting for verification steps. (#4982)
> 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
> 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] [Resolved] (GEODE-7959) Improve ConcurrentTestRunner in heavily loaded environment
[ https://issues.apache.org/jira/browse/GEODE-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-7959. -- Resolution: Won't Fix > Improve ConcurrentTestRunner in heavily loaded environment > -- > > Key: GEODE-7959 > URL: https://issues.apache.org/jira/browse/GEODE-7959 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Upgrading to Mockito 3.x seems to have trouble with tests using > ConcurrentTestRunner. The result is many threads stuck trying to capture > thread stacks in invocation of mock methods. > Review of code in ConcurrentTestRunner and LoopRunner shows reveals some > issues we should improve: > * LoopRunner.execute has a hot busy while loop > * the inner for-loop of LoopRunner.runTestMethod eats exceptions without > reporting them -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans of other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Summary: JMX managers may fail to federate mbeans of other members (was: Redundant JMX managers may not federate mbeans of other JMX managers) > JMX managers may fail to federate mbeans of other members > - > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans of other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Description: JMX Manager may fail to federate one or more MXBeans during startup because of a race condition involving FederatingManager and ManagementCacheListener. Change ManagementCacheListener to be ready upon construction. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. was: Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. > JMX managers may fail to federate mbeans of other members > - > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans during startup > because of a race condition involving FederatingManager and > ManagementCacheListener. > > Change ManagementCacheListener to be ready upon construction. > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans of other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Description: JMX Manager may fail to federate one or more MXBeans during startup because of a race condition involving FederatingManager and ManagementCacheListener. When ManagementCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. was: JMX Manager may fail to federate one or more MXBeans during startup because of a race condition involving FederatingManager and ManagementCacheListener. Change ManagementCacheListener to be ready upon construction. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. > JMX managers may fail to federate mbeans of other members > - > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans during startup because > of a race condition involving FederatingManager and ManagementCacheListener. > When ManagementCacheListener is first constructed, it is in a state that will > ignore all callbacks because the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Summary: JMX managers may fail to federate mbeans for other members (was: JMX managers may fail to federate mbeans of other members) > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans of other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Description: JMX Manager may fail to federate one or more MXBeans for other members because of a race condition during startup. When ManagementCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. was: JMX Manager may fail to federate one or more MXBeans during startup because of a race condition involving FederatingManager and ManagementCacheListener. When ManagementCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. > JMX managers may fail to federate mbeans of other members > - > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8012) JMX managers may fail to broadcast notifications for other members
[ https://issues.apache.org/jira/browse/GEODE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-8012: Assignee: Kirk Lund > JMX managers may fail to broadcast notifications for other members > -- > > Key: GEODE-8012 > URL: https://issues.apache.org/jira/browse/GEODE-8012 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > This is related to *GEODE-7739*. > JMX Manager may fail to broadcast notifications for other members because of > a race condition during startup. When NotificationCacheListener is first > constructed, it is in a state that will ignore all callbacks because the > field readyForEvents is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8012) JMX managers may fail to broadcast notifications for other members
Kirk Lund created GEODE-8012: Summary: JMX managers may fail to broadcast notifications for other members Key: GEODE-8012 URL: https://issues.apache.org/jira/browse/GEODE-8012 Project: Geode Issue Type: Improvement Components: jmx Reporter: Kirk Lund This is related to *GEODE-7739*. JMX Manager may fail to broadcast notifications for other members because of a race condition during startup. When NotificationCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8012) JMX managers may fail to broadcast notifications for other members
[ https://issues.apache.org/jira/browse/GEODE-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-8012: - Issue Type: Bug (was: Improvement) > JMX managers may fail to broadcast notifications for other members > -- > > Key: GEODE-8012 > URL: https://issues.apache.org/jira/browse/GEODE-8012 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Priority: Major > > This is related to *GEODE-7739*. > JMX Manager may fail to broadcast notifications for other members because of > a race condition during startup. When NotificationCacheListener is first > constructed, it is in a state that will ignore all callbacks because the > field readyForEvents is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Description: JMX Manager may fail to federate one or more MXBeans for other members because of a race condition during startup. When ManagementCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. Studying the JMX code also reveals the existence of *GEODE-8012*. was: JMX Manager may fail to federate one or more MXBeans for other members because of a race condition during startup. When ManagementCacheListener is first constructed, it is in a state that will ignore all callbacks because the field readyForEvents is false. Debugging with JMXMBeanReconnectDUnitTest revealed this bug. The test starts two locators with jmx manager configured and started. Locator1 always has all of locator2's mbeans, but locator2 is intermittently missing the personal mbeans of locator1. I think this is caused by some sort of race condition in the code that creates the monitoring regions for other members in locator2. It's possible that the jmx manager that hits this bug might fail to have mbeans for servers as well as other locators but I haven't seen a test case for this scenario. The exposure of this bug means that a user running more than one locator might have a locator that is missing one or more mbeans for the cluster. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7739: - Fix Version/s: (was: 1.13.0) > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-7710:
-
Description:
Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
the locators missing the LockServiceMXBean for the cluster config service.
{noformat}
but could not find:
<[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
{noformat}
These test failures are caused by *GEODE-7739*.
was:
Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
the locators missing the LockServiceMXBean for the cluster config service.
{noformat}
but could not find:
<[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
{noformat}
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090001#comment-17090001 ] ASF subversion and git services commented on GEODE-7864: Commit 6d08055d32bb5ea4677dee2d958bc99a99d8ba7e in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d08055 ] GEODE-7864: Removing null checks that are not required.(Part 1) (#4880) > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[
https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090013#comment-17090013
]
ASF GitHub Bot commented on GEODE-7851:
---
demery-pivotal commented on a change in pull request #4977:
URL: https://github.com/apache/geode/pull/4977#discussion_r413302656
##
File path:
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
##
@@ -80,8 +88,95 @@ public Repository(OAuth2AuthorizedClientService
authorizedClientService,
this.clusterFactory = clusterFactory;
}
+ /**
+ * this will return a cluster already connected to the geode jmx manager for
the user in the
+ * request
+ *
+ * But for multi-user connections to gemfireJMX, i.e pulse that uses gemfire
integrated security,
+ * we will need to get the username from the context
+ */
+ public Cluster getCluster() {
+Authentication authentication =
SecurityContextHolder.getContext().getAuthentication();
+if (authentication == null) {
+ return null;
+}
+
+if (authentication instanceof OAuth2AuthenticationToken) {
+ return getClusterWithAuthenticationToken((OAuth2AuthenticationToken)
authentication);
+}
+
+return getClusterWithUserNameAndPassword(authentication.getName(), null);
+ }
+
+ public Cluster getClusterWithUserNameAndPassword(String userName, String
password) {
+String[] credentials = {userName, password};
+return getClusterWithCredentials(userName, credentials);
+ }
+
+ public Cluster getClusterWithCredentials(String userName, Object
credentials) {
+synchronized (clusterMap) {
+ Cluster cluster = clusterMap.get(userName);
+ if (cluster == null) {
+logger.info(resourceBundle.getString("LOG_MSG_CREATE_NEW_THREAD") + "
: " + userName);
+cluster = clusterFactory.create(host, port, userName, resourceBundle,
this);
+// Assign name to thread created
+cluster.setName(PulseConstants.APP_NAME + "-" + host + ":" + port +
":" + userName);
+cluster.connectToGemFire(credentials);
+if (cluster.isConnectedFlag()) {
+ clusterMap.put(userName, cluster);
+}
+ }
+ return cluster;
+}
+ }
+
+ /**
+ * Returns the cluster for the user associated with the given
authentication. If the user's
+ * access token is expired, it is refreshed and the cluster is reconnected
to JMX using the fresh
+ * token. If the refresh fails, the user's cluster is disconnected from JMX
and removed from the
+ * repository.
+ */
+ private Cluster getClusterWithAuthenticationToken(OAuth2AuthenticationToken
authentication) {
+OAuth2AuthorizedClient authorizedClient =
getAuthorizedClient(authentication);
+
+if (isExpired(authorizedClient.getAccessToken())) {
Review comment:
`logoutUser()` discards any data cached in the `Cluster`, including all
of the trends stored in circular buffers. That seems like a harsh thing to do
when the token refreshes.
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
> 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
> 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-7678) Partitioned Region clear operations must invoke cache level listeners
[ https://issues.apache.org/jira/browse/GEODE-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090064#comment-17090064 ] ASF GitHub Bot commented on GEODE-7678: --- agingade opened a new pull request #4987: URL: https://github.com/apache/geode/pull/4987 The changes are made to PR clear messaging and locking mechanism to preserve cache-listener and client-events ordering during concurrent cache operation while clear in progress. 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: - [Y] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [Y] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [Y] Is your initial contribution a single, squashed commit? - [Y] Does `gradlew build` run cleanly? - [Y] Have you written or updated unit tests to verify your changes? - [NA] 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 > Partitioned Region clear operations must invoke cache level listeners > - > > Key: GEODE-7678 > URL: https://issues.apache.org/jira/browse/GEODE-7678 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > Clear operations are successful and CacheListener.afterRegionClear(), > CacheWriter.beforeRegionClear() are invoked. > > Acceptance : > * DUnit tests validating the above behavior. > * 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-7667) GFSH commands - uniform gfsh command to clear regions
[
https://issues.apache.org/jira/browse/GEODE-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090073#comment-17090073
]
ASF GitHub Bot commented on GEODE-7667:
---
DonalEvans commented on a change in pull request #4818:
URL: https://github.com/apache/geode/pull/4818#discussion_r413387539
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClearRvvLockingDUnitTest.java
##
@@ -51,7 +51,7 @@
/**
* Test class to verify proper RVV locking interaction between entry
operations such as PUT/REMOVE
- * and the CLEAR region operation
+ * and the CLEAR_REGION region operation
Review comment:
Another accidental rename.
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/cache30/RegionReliabilityTestCase.java
##
@@ -1341,7 +1341,7 @@ public void run() {
// pass
}
-// CLEAR
+// CLEAR_REGION
Review comment:
I think that several of these renames were accidentally included when
changing the Cli string. They should be put back how they were.
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ClearTXLockingDUnitTest.java
##
@@ -43,19 +43,20 @@
import org.apache.geode.test.dunit.rules.DistributedRule;
/**
- * Test class to verify proper locking interaction between transactions and
the CLEAR region
+ * Test class to verify proper locking interaction between transactions and
the CLEAR_REGION region
Review comment:
More accidental renames in this file.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/DiskStoreImpl.java
##
@@ -3509,7 +3509,7 @@ public String toString() {
if (de != null) {
sb.append(" key=").append(de.getKey());
} else {
-sb.append(" ");
+sb.append(" ");
Review comment:
Accidental rename.
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
> GFSH commands - uniform gfsh command to clear regions
> -
>
> Key: GEODE-7667
> URL: https://issues.apache.org/jira/browse/GEODE-7667
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Nabarun Nag
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeCommons, docs
> Time Spent: 5h
> Remaining Estimate: 0h
>
> * Currently, the gfsh command to clear replicated region is called ‘remove
> —region=/regionName’.
> * Replace this command with ‘clear region —region=regionName’
> * While executing this gfsh command on partitioned regions, this should call
> the clear() Java API using the gfsh function execution machinery.
> * Point to note is that this command should take into consideration of the
> coordinator selection and how this command is distributed to the members
> Acceptance :
> * There should be ‘clear region —region=/regionName’ gfsh command
> * DUnit tests to verify that command can be executed successfully on
> PartitionedRegion
> * Deprecate the remove command, as remove does not mean clear
> * Unit tests with complete code coverage for the newly written code.
> * Test coverage to when a member departs in this scenario
> * Test coverage to when a member restarts in this scenario
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[
https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090085#comment-17090085
]
ASF GitHub Bot commented on GEODE-7851:
---
jinmeiliao commented on a change in pull request #4977:
URL: https://github.com/apache/geode/pull/4977#discussion_r413403957
##
File path: geode-pulse/build.gradle
##
@@ -50,7 +50,9 @@ dependencies {
// Needed to fully use log4j instead of commons-logging.
implementation('org.apache.logging.log4j:log4j-jcl')
implementation('org.apache.logging.log4j:log4j-api')
-// implementation('org.apache.logging.log4j:log4j-core')
+ implementation('org.apache.logging.log4j:log4j-slf4j-impl') {
Review comment:
probably it would be good to do this in a separate PR so that we can
backport this to support branches.
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
> 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
> 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-7678) Partitioned Region clear operations must invoke cache level listeners
[ https://issues.apache.org/jira/browse/GEODE-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090086#comment-17090086 ] ASF GitHub Bot commented on GEODE-7678: --- lgtm-com[bot] commented on issue #4987: URL: https://github.com/apache/geode/pull/4987#issuecomment-618094081 This pull request **introduces 1 alert** when merging 90928f3c68edbb010f103755a9279e5067fbafe5 into e87b3b7ab7cb48d2a4be9b114443dda56bfd9d70 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-8301776a6101a07aedfd1e855dfb524329ff556c) **new alerts:** * 1 for Non\-synchronized override of synchronized method This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Partitioned Region clear operations must invoke cache level listeners > - > > Key: GEODE-7678 > URL: https://issues.apache.org/jira/browse/GEODE-7678 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > Clear operations are successful and CacheListener.afterRegionClear(), > CacheWriter.beforeRegionClear() are invoked. > > Acceptance : > * DUnit tests validating the above behavior. > * 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)
[GitHub] [geode] lgtm-com[bot] commented on issue #4987: GEODE-7678: Support for cache-listener and client-notification for Partitioned Region Clear operation.
lgtm-com[bot] commented on issue #4987: URL: https://github.com/apache/geode/pull/4987#issuecomment-618094081 This pull request **introduces 1 alert** when merging 90928f3c68edbb010f103755a9279e5067fbafe5 into e87b3b7ab7cb48d2a4be9b114443dda56bfd9d70 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-8301776a6101a07aedfd1e855dfb524329ff556c) **new alerts:** * 1 for Non\-synchronized override of synchronized method This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17090092#comment-17090092
]
ASF GitHub Bot commented on GEODE-7953:
---
upthewaterspout commented on a change in pull request #4909:
URL: https://github.com/apache/geode/pull/4909#discussion_r413406711
##
File path:
geode-core/src/main/java/org/apache/geode/cache/control/RegionRedundancyStatus.java
##
@@ -0,0 +1,158 @@
+/*
+ * 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.cache.control;
+
+import java.io.DataInput;
+import java.io.DataOutput;
+import java.io.IOException;
+
+import org.apache.geode.DataSerializer;
+import org.apache.geode.internal.cache.PartitionedRegion;
+import org.apache.geode.internal.serialization.DataSerializableFixedID;
+import org.apache.geode.internal.serialization.DeserializationContext;
+import org.apache.geode.internal.serialization.SerializationContext;
+import org.apache.geode.internal.serialization.Version;
+
+/**
+ * Used to calculate and store the redundancy status for a {@link
PartitionedRegion}.
+ */
+public class RegionRedundancyStatus implements DataSerializableFixedID {
Review comment:
I think this is still leaking internal classes (in this case
DataSerializableFixedID). This probably needs another (read only) interface as
part of the public API and an internal implementation class.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090101#comment-17090101
]
Ivan Godwin commented on GEODE-7822:
CI failure: Another test within the same class has failed.
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/85
{code:java}
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
testPRClientPutRejection FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$41.run in VM
0 running on Host 599212ead077 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.cache.management.MemoryThresholdsOffHeapDUnitTest.doClientServerTest(MemoryThresholdsOffHeapDUnitTest.java:1597)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRClientPutRejection(MemoryThresholdsOffHeapDUnitTest.java:1407)
Caused by:
java.lang.AssertionError: expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$OffHeapMemoryMonitorObserverImpl.verifyBeginUpdateMemoryUsed(MemoryThresholdsOffHeapDUnitTest.java:1674)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$41.run(MemoryThresholdsOffHeapDUnitTest.java:1608)
{code}
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFa
[jira] [Commented] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[
https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090109#comment-17090109
]
ASF GitHub Bot commented on GEODE-7851:
---
demery-pivotal commented on a change in pull request #4977:
URL: https://github.com/apache/geode/pull/4977#discussion_r413425777
##
File path: geode-pulse/build.gradle
##
@@ -50,7 +50,9 @@ dependencies {
// Needed to fully use log4j instead of commons-logging.
implementation('org.apache.logging.log4j:log4j-jcl')
implementation('org.apache.logging.log4j:log4j-api')
-// implementation('org.apache.logging.log4j:log4j-core')
+ implementation('org.apache.logging.log4j:log4j-slf4j-impl') {
Review comment:
Okay. And probably it should be `runtimeOnly` instead of `implementation`
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
> 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
> 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-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090132#comment-17090132 ] ASF GitHub Bot commented on GEODE-7851: --- demery-pivotal opened a new pull request #4988: URL: https://github.com/apache/geode/pull/4988 Pulse was not logging because its war file had no slf4j implementation. This commit adds the log4j2 implementation to the war file. Authored-by: Dale Emery 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 > 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 > 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-7851) Pulse should support OAuth2 authorization code flow
[
https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090135#comment-17090135
]
ASF GitHub Bot commented on GEODE-7851:
---
demery-pivotal commented on a change in pull request #4977:
URL: https://github.com/apache/geode/pull/4977#discussion_r413431474
##
File path:
geode-pulse/src/main/java/org/apache/geode/tools/pulse/internal/data/Repository.java
##
@@ -80,8 +88,95 @@ public Repository(OAuth2AuthorizedClientService
authorizedClientService,
this.clusterFactory = clusterFactory;
}
+ /**
+ * this will return a cluster already connected to the geode jmx manager for
the user in the
+ * request
+ *
+ * But for multi-user connections to gemfireJMX, i.e pulse that uses gemfire
integrated security,
+ * we will need to get the username from the context
+ */
+ public Cluster getCluster() {
+Authentication authentication =
SecurityContextHolder.getContext().getAuthentication();
+if (authentication == null) {
+ return null;
+}
+
+if (authentication instanceof OAuth2AuthenticationToken) {
+ return getClusterWithAuthenticationToken((OAuth2AuthenticationToken)
authentication);
+}
+
+return getClusterWithUserNameAndPassword(authentication.getName(), null);
+ }
+
+ public Cluster getClusterWithUserNameAndPassword(String userName, String
password) {
+String[] credentials = {userName, password};
+return getClusterWithCredentials(userName, credentials);
+ }
+
+ public Cluster getClusterWithCredentials(String userName, Object
credentials) {
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
> 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
> 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-7851) Pulse should support OAuth2 authorization code flow
[
https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090136#comment-17090136
]
ASF GitHub Bot commented on GEODE-7851:
---
demery-pivotal commented on a change in pull request #4977:
URL: https://github.com/apache/geode/pull/4977#discussion_r413431615
##
File path: geode-pulse/build.gradle
##
@@ -50,7 +50,9 @@ dependencies {
// Needed to fully use log4j instead of commons-logging.
implementation('org.apache.logging.log4j:log4j-jcl')
implementation('org.apache.logging.log4j:log4j-api')
-// implementation('org.apache.logging.log4j:log4j-core')
+ implementation('org.apache.logging.log4j:log4j-slf4j-impl') {
Review comment:
Done: https://github.com/apache/geode/pull/4988
And I rebased this PR on that one.
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
> 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
> 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-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=17090294#comment-17090294 ] ASF GitHub Bot commented on GEODE-7309: --- mkevo commented on issue #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-618198674 > We are still getting stack overflow errors in my rolling upgrade use cases, let me investigate a bit more. Hi @nabarunnag, can you share your tests with us so we can help you? Also internal tests should not block merging to an open source project. 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)
[GitHub] [geode] mkevo commented on issue #4395: GEODE-7309: upgrade Lucene to 7.1.0
mkevo commented on issue #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-618198674 > We are still getting stack overflow errors in my rolling upgrade use cases, let me investigate a bit more. Hi @nabarunnag, can you share your tests with us so we can help you? Also internal tests should not block merging to an open source project. 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
[GitHub] [geode] mkevo commented on issue #4975: Logging documentation fixes
mkevo commented on issue #4975: URL: https://github.com/apache/geode/pull/4975#issuecomment-618199863 Since it was changed according to the comment, I will merge 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
[jira] [Assigned] (GEODE-8013) Fix logging documentation
[ https://issues.apache.org/jira/browse/GEODE-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-8013: - Assignee: Alberto Bustamante Reyes > Fix logging documentation > - > > Key: GEODE-8013 > URL: https://issues.apache.org/jira/browse/GEODE-8013 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Mario Kevo >Assignee: Alberto Bustamante Reyes >Priority: Major > > Link to the conversation on dev list: > [https://markmail.org/thread/a6gobaphywmkm7gq] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8013) Fix logging documentation
Mario Kevo created GEODE-8013: - Summary: Fix logging documentation Key: GEODE-8013 URL: https://issues.apache.org/jira/browse/GEODE-8013 Project: Geode Issue Type: Task Components: docs Reporter: Mario Kevo Link to the conversation on dev list: [https://markmail.org/thread/a6gobaphywmkm7gq] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [geode] mkevo edited a comment on issue #4975: Logging documentation fixes
mkevo edited a comment on issue #4975: URL: https://github.com/apache/geode/pull/4975#issuecomment-618199863 Since it was changed according to the comment, I will merge this. Also I created a new ticket to easier track this in the future. 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
[jira] [Commented] (GEODE-8013) Fix logging documentation
[ https://issues.apache.org/jira/browse/GEODE-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090303#comment-17090303 ] ASF subversion and git services commented on GEODE-8013: Commit ee606776d2103fbe87c250ac379d35b03a11c5fc in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee60677 ] GEODE-8013: Logging documentation fixes (#4975) * Logging documentation fixes * Re-wording after review * Empty commit to retrigger CI > Fix logging documentation > - > > Key: GEODE-8013 > URL: https://issues.apache.org/jira/browse/GEODE-8013 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Mario Kevo >Assignee: Alberto Bustamante Reyes >Priority: Major > > Link to the conversation on dev list: > [https://markmail.org/thread/a6gobaphywmkm7gq] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8013) Fix logging documentation
[ https://issues.apache.org/jira/browse/GEODE-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-8013. --- Fix Version/s: 1.13.0 Resolution: Fixed > Fix logging documentation > - > > Key: GEODE-8013 > URL: https://issues.apache.org/jira/browse/GEODE-8013 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Mario Kevo >Assignee: Alberto Bustamante Reyes >Priority: Major > Fix For: 1.13.0 > > > Link to the conversation on dev list: > [https://markmail.org/thread/a6gobaphywmkm7gq] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [geode] mivanac commented on issue #4387: GEODE-7458: Adding option in gfsh command "start gateway sender" to control clearing of existing queues
mivanac commented on issue #4387: URL: https://github.com/apache/geode/pull/4387#issuecomment-618210584 Hi, Are there any updates regarding this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GEODE-7458) Adding additional option in gfsh command "start gateway sender" to control clearing of existing queues
[ https://issues.apache.org/jira/browse/GEODE-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090317#comment-17090317 ] ASF GitHub Bot commented on GEODE-7458: --- mivanac commented on issue #4387: URL: https://github.com/apache/geode/pull/4387#issuecomment-618210584 Hi, Are there any updates regarding this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Adding additional option in gfsh command "start gateway sender" to control > clearing of existing queues > --- > > Key: GEODE-7458 > URL: https://issues.apache.org/jira/browse/GEODE-7458 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > We would like to add additional option in gfsh command "start gateway sender" > to control clearing of existing queues --cleanQueues. > > This option will indicate, when gateway sender is started, should we > discard/clean existing queue, or should we use existing queue. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
