[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=17091266#comment-17091266 ] ASF subversion and git services commented on GEODE-8006: Commit 9b1d65264b44e426857c1934c5af4c250c86ff13 in geode's branch refs/heads/mass-test-run 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 > 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)
[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=17091264#comment-17091264 ] ASF subversion and git services commented on GEODE-8010: Commit 471f49e1cfe0591077a53f5418f7355fe46e5528 in geode's branch refs/heads/mass-test-run 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 > 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-8013) Fix logging documentation
[ https://issues.apache.org/jira/browse/GEODE-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091270#comment-17091270 ] ASF subversion and git services commented on GEODE-8013: Commit ee606776d2103fbe87c250ac379d35b03a11c5fc in geode's branch refs/heads/mass-test-run 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 > 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)
[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=17091268#comment-17091268
]
ASF subversion and git services commented on GEODE-7935:
Commit 65dd63e2b4c05f180e40e94afc94b51d2ac57626 in geode's branch
refs/heads/mass-test-run 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] [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=17091271#comment-17091271 ] ASF subversion and git services commented on GEODE-7851: Commit 0f512f005a78187c2797dfac85135fcfcdae43ea in geode's branch refs/heads/mass-test-run from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f512f0 ] GEODE-7851: Add slf4j implementation to Pulse (#4988) * GEODE-7851: Add slf4j implementation to Pulse 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 * Add test; simplify dependency declaration > 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-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=17091265#comment-17091265 ] ASF subversion and git services commented on GEODE-7981: Commit d6c8c8c5f269aba9d424136c92b88d285ec6d5b2 in geode's branch refs/heads/mass-test-run 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] [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=17091272#comment-17091272 ] ASF subversion and git services commented on GEODE-7851: Commit 0f512f005a78187c2797dfac85135fcfcdae43ea in geode's branch refs/heads/mass-test-run from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f512f0 ] GEODE-7851: Add slf4j implementation to Pulse (#4988) * GEODE-7851: Add slf4j implementation to Pulse 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 * Add test; simplify dependency declaration > 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-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091269#comment-17091269 ] ASF subversion and git services commented on GEODE-7864: Commit 6d08055d32bb5ea4677dee2d958bc99a99d8ba7e in geode's branch refs/heads/mass-test-run 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-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=17091267#comment-17091267
]
ASF subversion and git services commented on GEODE-7957:
Commit 1ddd7de1d9b6c7c37f14db06f98acb769bd99b68 in geode's branch
refs/heads/mass-test-run 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
> 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-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=17091278#comment-17091278
]
ASF subversion and git services commented on GEODE-7957:
Commit 1ddd7de1d9b6c7c37f14db06f98acb769bd99b68 in geode's branch
refs/heads/mass-test-run 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
> 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-7935) CI Failure: GridAdvisorDUnitTest.test2by2usingGroups
[
https://issues.apache.org/jira/browse/GEODE-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091279#comment-17091279
]
ASF subversion and git services commented on GEODE-7935:
Commit 65dd63e2b4c05f180e40e94afc94b51d2ac57626 in geode's branch
refs/heads/mass-test-run 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] [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=17091275#comment-17091275 ] ASF subversion and git services commented on GEODE-8010: Commit 471f49e1cfe0591077a53f5418f7355fe46e5528 in geode's branch refs/heads/mass-test-run 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 > 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-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=17091283#comment-17091283 ] ASF subversion and git services commented on GEODE-7851: Commit 0f512f005a78187c2797dfac85135fcfcdae43ea in geode's branch refs/heads/mass-test-run from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f512f0 ] GEODE-7851: Add slf4j implementation to Pulse (#4988) * GEODE-7851: Add slf4j implementation to Pulse 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 * Add test; simplify dependency declaration > 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-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=17091276#comment-17091276 ] ASF subversion and git services commented on GEODE-7981: Commit d6c8c8c5f269aba9d424136c92b88d285ec6d5b2 in geode's branch refs/heads/mass-test-run 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] [Commented] (GEODE-8006) .asf.yaml notifications
[ https://issues.apache.org/jira/browse/GEODE-8006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091277#comment-17091277 ] ASF subversion and git services commented on GEODE-8006: Commit 9b1d65264b44e426857c1934c5af4c250c86ff13 in geode's branch refs/heads/mass-test-run 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 > 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)
[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=17091281#comment-17091281 ] ASF subversion and git services commented on GEODE-8013: Commit ee606776d2103fbe87c250ac379d35b03a11c5fc in geode's branch refs/heads/mass-test-run 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 > 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)
[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=17091280#comment-17091280 ] ASF subversion and git services commented on GEODE-7864: Commit 6d08055d32bb5ea4677dee2d958bc99a99d8ba7e in geode's branch refs/heads/mass-test-run 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=17091282#comment-17091282 ] ASF subversion and git services commented on GEODE-7851: Commit 0f512f005a78187c2797dfac85135fcfcdae43ea in geode's branch refs/heads/mass-test-run from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f512f0 ] GEODE-7851: Add slf4j implementation to Pulse (#4988) * GEODE-7851: Add slf4j implementation to Pulse 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 * Add test; simplify dependency declaration > 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-7565) Wrong management of receivers with same hostname-for-senders
[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091322#comment-17091322
]
ASF GitHub Bot commented on GEODE-7565:
---
jujoramos commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r414385715
##
File path:
geode-core/src/main/java/org/apache/geode/cache/client/internal/PingOp.java
##
@@ -65,8 +71,9 @@ protected boolean needsUserId() {
@Override
protected void sendMessage(Connection cnx) throws Exception {
getMessage().clearMessageHasSecurePartFlag();
- this.startTime = System.currentTimeMillis();
- getMessage().send(false);
+ getMessage().setNumberOfParts(1);
+ getMessage().addObjPart(serverID);
+ getMessage().send(true);
Review comment:
No problem at all, I was just checking as I saw other messages execute
the entire configuration logic (set number of parts, adding parts, etc.)
directly in the constructor.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Wrong management of receivers with same hostname-for-senders
>
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull
> Time Spent: 8h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
>
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not cheap from OAM
> and resources perspective in cloud native environments and also limit some
> important use-cases (like scaling).
>
> Link to thread in DEV mailing list:
> [https://markmail.org/thread/6qakx67rxiokdsec]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091342#comment-17091342
]
ASF GitHub Bot commented on GEODE-7565:
---
alb3rtobr commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r414405668
##
File path:
geode-core/src/main/java/org/apache/geode/cache/client/internal/PingOp.java
##
@@ -65,8 +71,9 @@ protected boolean needsUserId() {
@Override
protected void sendMessage(Connection cnx) throws Exception {
getMessage().clearMessageHasSecurePartFlag();
- this.startTime = System.currentTimeMillis();
- getMessage().send(false);
+ getMessage().setNumberOfParts(1);
+ getMessage().addObjPart(serverID);
+ getMessage().send(true);
Review comment:
thanks @bschuchardt
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Wrong management of receivers with same hostname-for-senders
>
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull
> Time Spent: 8h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
>
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not cheap from OAM
> and resources perspective in cloud native environments and also limit some
> important use-cases (like scaling).
>
> Link to thread in DEV mailing list:
> [https://markmail.org/thread/6qakx67rxiokdsec]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091521#comment-17091521
]
ASF GitHub Bot commented on GEODE-7565:
---
jujoramos commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r414535620
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Ping.java
##
@@ -50,11 +51,17 @@ public void cmdExecute(final Message clientMessage, final
ServerConnection serve
}
if (clientMessage.getNumberOfParts() > 0) {
try {
-DistributedMember targetServer = (DistributedMember)
clientMessage.getPart(0).getObject();
-DistributedMember myID = serverConnection.getCache().getMyId();
+InternalDistributedMember targetServer =
+(InternalDistributedMember) clientMessage.getPart(0).getObject();
+InternalDistributedMember myID = serverConnection.getCache().getMyId();
if (!myID.equals(targetServer)) {
- pingCorrectServer(clientMessage, targetServer, serverConnection);
- writeReply(clientMessage, serverConnection);
+ if (myID.compareTo(targetServer.getMemberIdentifier(), true, false)
== 0) {
Review comment:
The issue described
[here](https://issues.apache.org/jira/browse/GEODE-8004?focusedCommentId=17090468&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17090468)
still remains, you're comparing `myID` (instance of
`InternalDistributedMember`) against `targetServer.getMemberIdentifier()`
(instance of `MemberIdentifier`), so the comparison fails with a
`ClassCastException` and the client logs the following:
```
[warn 2020/04/24 01:33:02.869 PDT tid=0x112]
Pool unexpected java.lang.ClassCastException: [B cannot be cast to
java.lang.Throwable connection=Pooled Connection to
rs-GEM-2885-0120a0i32xlarge-hydra-client-4:20245: Connection[DESTROYED]).
Server unreachable: could not connect after 1 attempts
```
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
##
@@ -641,4 +641,8 @@ public UUID getUUID() {
public interface HostnameResolver {
InetAddress getInetAddress(ServerLocation location) throws
UnknownHostException;
}
+
+ public MemberIdentifier getMemberIdentifier() {
+return memberIdentifier;
+ }
Review comment:
You don't need to expose the `MemberIdentifier` here, you can directly
use `InternalDistributedMember.compareTo(DistributedMember o, boolean
compareMemberData, boolean compareViewIds)`, which internally delegates to the
`MemberIdentifier` 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
> Wrong management of receivers with same hostname-for-senders
>
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull
> Time Spent: 8h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
>
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not cheap from OAM
> and resources perspective in cloud native environments and also limit some
> important use-cases (like scaling).
>
> Link to thread in DEV mailing list:
> [https://markmail.org/thread/6qakx67rxiokdsec]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8015) Need to add symbol files (.pdb) to install for Windows builds
[ https://issues.apache.org/jira/browse/GEODE-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091542#comment-17091542 ] ASF GitHub Bot commented on GEODE-8015: --- pdxcodemonkey opened a new pull request #592: URL: https://github.com/apache/geode-native/pull/592 - Valid for Debug and RelWithDebInfo configs @vfordpivotal @mreddington @davebarnes97 @dihardman @karensmolermiller 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 > Need to add symbol files (.pdb) to install for Windows builds > - > > Key: GEODE-8015 > URL: https://issues.apache.org/jira/browse/GEODE-8015 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > As a client app developer, I may need/wish to debug into the Geode native > library when tracking down an issue. To do this, I will need proper symbols > for the debugger. For Windows platforms, symbols reside in a separate file > from the library, so in order to have them in the same place as the library, > they will need to be copied into the same location when I run `cmake --build > . --target install` from the command line, or the equivalent in and IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[
https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091563#comment-17091563
]
ASF GitHub Bot commented on GEODE-7565:
---
alb3rtobr commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r414567295
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Ping.java
##
@@ -55,12 +55,11 @@ public void cmdExecute(final Message clientMessage, final
ServerConnection serve
(InternalDistributedMember) clientMessage.getPart(0).getObject();
InternalDistributedMember myID = serverConnection.getCache().getMyId();
if (!myID.equals(targetServer)) {
- if (myID.compareTo(targetServer.getMemberIdentifier(), true, false)
== 0) {
+ if (myID.compareTo(targetServer, true, false) == 0) {
logger.warn("Target server {} has different viewId {}",
targetServer, myID);
writeErrorResponse(clientMessage, MessageType.EXCEPTION,
serverConnection);
} else {
pingCorrectServer(clientMessage, targetServer, serverConnection);
-writeReply(clientMessage, serverConnection);
Review comment:
@jujoramos Implementing tests I realized this writeReply here is
duplicated, `pingCorrectServer` is already calling it when the ping is
forwarded. So this should be the cause for the error you saw about an
unexpected REPLY message.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Wrong management of receivers with same hostname-for-senders
>
>
> Key: GEODE-7565
> URL: https://issues.apache.org/jira/browse/GEODE-7565
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull
> Time Spent: 8h
> Remaining Estimate: 0h
>
> There is a problem with Geode WAN replication when GW receivers are
> configured with the same hostname-for-senders and port on all servers. [ 1 ]
> The problem experienced is that shutting down one server is stopping
> replication to this cluster until the server is up again. This is because
> Geode incorrectly assumes there are no more alive servers when just one of
> them is down, because since they share hostname-for-senders and port, they
> are treated as one same server.
> Our proposal consists on expanding internal data in locators with enough
> information to distinguish servers in the beforementioned use case. The same
> intervention is likely needed in the client pools and possibly elsewhere in
> the source code.
>
> [ 1 ] : The reason for such a setup is deploying Geode cluster on a
> Kubernetes cluster where all GW receivers are reachable from the outside
> world on the same VIP and port. Other kinds of configuration (different
> hostname and/or different port for each GW receiver) are not cheap from OAM
> and resources perspective in cloud native environments and also limit some
> important use-cases (like scaling).
>
> Link to thread in DEV mailing list:
> [https://markmail.org/thread/6qakx67rxiokdsec]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8018) Update .lgtm.yml to latest (1.12) Geode release
[ https://issues.apache.org/jira/browse/GEODE-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091590#comment-17091590 ] ASF subversion and git services commented on GEODE-8018: Commit 996e77fe236a886e3873e56be17dd9cc42ae8712 in geode-native's branch refs/heads/develop from M. Oleske [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=996e77f ] GEODE-8018: Update .lgtm.yml to latest Geode release (1.12) (#586) > Update .lgtm.yml to latest (1.12) Geode release > --- > > Key: GEODE-8018 > URL: https://issues.apache.org/jira/browse/GEODE-8018 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Blake Bender >Priority: Major > > Geode 1.12 is out now, so we need to update LGTM to the latest version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8018) Update .lgtm.yml to latest (1.12) Geode release
Blake Bender created GEODE-8018: --- Summary: Update .lgtm.yml to latest (1.12) Geode release Key: GEODE-8018 URL: https://issues.apache.org/jira/browse/GEODE-8018 Project: Geode Issue Type: Task Components: native client Reporter: Blake Bender Geode 1.12 is out now, so we need to update LGTM to the latest version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[ https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091601#comment-17091601 ] ASF GitHub Bot commented on GEODE-7565: --- alb3rtobr commented on pull request #4978: URL: https://github.com/apache/geode/pull/4978#issuecomment-619030061 > @alb3rtobr: I've executed the tests again and still see some failures, see my inline comments within the `Ping.java` class. > As a side note, I still don't see tests added to this pull request (only one new, which is really scarce considering the amount of changes introduced through `GEODE-7565`), please add multiple tests to verify all the code changes and additions. I hope last two commits solve the failure I introduced, sorry for that. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Wrong management of receivers with same hostname-for-senders > > > Key: GEODE-7565 > URL: https://issues.apache.org/jira/browse/GEODE-7565 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull > Time Spent: 8h > Remaining Estimate: 0h > > There is a problem with Geode WAN replication when GW receivers are > configured with the same hostname-for-senders and port on all servers. [ 1 ] > The problem experienced is that shutting down one server is stopping > replication to this cluster until the server is up again. This is because > Geode incorrectly assumes there are no more alive servers when just one of > them is down, because since they share hostname-for-senders and port, they > are treated as one same server. > Our proposal consists on expanding internal data in locators with enough > information to distinguish servers in the beforementioned use case. The same > intervention is likely needed in the client pools and possibly elsewhere in > the source code. > > [ 1 ] : The reason for such a setup is deploying Geode cluster on a > Kubernetes cluster where all GW receivers are reachable from the outside > world on the same VIP and port. Other kinds of configuration (different > hostname and/or different port for each GW receiver) are not cheap from OAM > and resources perspective in cloud native environments and also limit some > important use-cases (like scaling). > > Link to thread in DEV mailing list: > [https://markmail.org/thread/6qakx67rxiokdsec] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7565) Wrong management of receivers with same hostname-for-senders
[ https://issues.apache.org/jira/browse/GEODE-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091613#comment-17091613 ] ASF GitHub Bot commented on GEODE-7565: --- jujoramos commented on pull request #4978: URL: https://github.com/apache/geode/pull/4978#issuecomment-619040254 > I hope last two commits solve the failure I introduced, sorry for that. Thanks, I need to have a look and run the tests again; will let you know the results early next week. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Wrong management of receivers with same hostname-for-senders > > > Key: GEODE-7565 > URL: https://issues.apache.org/jira/browse/GEODE-7565 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull > Time Spent: 8h > Remaining Estimate: 0h > > There is a problem with Geode WAN replication when GW receivers are > configured with the same hostname-for-senders and port on all servers. [ 1 ] > The problem experienced is that shutting down one server is stopping > replication to this cluster until the server is up again. This is because > Geode incorrectly assumes there are no more alive servers when just one of > them is down, because since they share hostname-for-senders and port, they > are treated as one same server. > Our proposal consists on expanding internal data in locators with enough > information to distinguish servers in the beforementioned use case. The same > intervention is likely needed in the client pools and possibly elsewhere in > the source code. > > [ 1 ] : The reason for such a setup is deploying Geode cluster on a > Kubernetes cluster where all GW receivers are reachable from the outside > world on the same VIP and port. Other kinds of configuration (different > hostname and/or different port for each GW receiver) are not cheap from OAM > and resources perspective in cloud native environments and also limit some > important use-cases (like scaling). > > Link to thread in DEV mailing list: > [https://markmail.org/thread/6qakx67rxiokdsec] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8015) Need to add symbol files (.pdb) to install for Windows builds
[
https://issues.apache.org/jira/browse/GEODE-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091625#comment-17091625
]
ASF GitHub Bot commented on GEODE-8015:
---
pivotal-jbarrett commented on a change in pull request #592:
URL: https://github.com/apache/geode-native/pull/592#discussion_r414628141
##
File path: clicache/src/CMakeLists.txt
##
@@ -352,6 +352,13 @@ install(TARGETS ${PROJECT_NAME}
ARCHIVE DESTINATION lib
)
+IF(MSVC)
+ INSTALL ( FILES ${CMAKE_CURRENT_BINARY_DIR}/$/${PRODUCT_DLL_NAME}.pdb
Review comment:
$
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Need to add symbol files (.pdb) to install for Windows builds
> -
>
> Key: GEODE-8015
> URL: https://issues.apache.org/jira/browse/GEODE-8015
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> As a client app developer, I may need/wish to debug into the Geode native
> library when tracking down an issue. To do this, I will need proper symbols
> for the debugger. For Windows platforms, symbols reside in a separate file
> from the library, so in order to have them in the same place as the library,
> they will need to be copied into the same location when I run `cmake --build
> . --target install` from the command line, or the equivalent in and IDE.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8015) Need to add symbol files (.pdb) to install for Windows builds
[ https://issues.apache.org/jira/browse/GEODE-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091661#comment-17091661 ] ASF subversion and git services commented on GEODE-8015: Commit a34a5e699cf3ee766e9299ec8b9d8fe4e6a02057 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=a34a5e6 ] GEODE-8015: Install PDB (symbol) files on Windows builds (#592) - Valid for Debug and RelWithDebInfo configs > Need to add symbol files (.pdb) to install for Windows builds > - > > Key: GEODE-8015 > URL: https://issues.apache.org/jira/browse/GEODE-8015 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > As a client app developer, I may need/wish to debug into the Geode native > library when tracking down an issue. To do this, I will need proper symbols > for the debugger. For Windows platforms, symbols reside in a separate file > from the library, so in order to have them in the same place as the library, > they will need to be copied into the same location when I run `cmake --build > . --target install` from the command line, or the equivalent in and IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8019) Extend information about what from Delta Propagation is used in transactions
Alberto Gomez created GEODE-8019:
Summary: Extend information about what from Delta Propagation is
used in transactions
Key: GEODE-8019
URL: https://issues.apache.org/jira/browse/GEODE-8019
Project: Geode
Issue Type: Improvement
Components: docs
Reporter: Alberto Gomez
The Geode documentation says the following when talking about Delta Propagation
and transactions:
Geode also does not propagate deltas for:
* Transactional commit
...
That statement is not clear about what exactly is used from Delta Propagation
in transactions. The information should be extended to make it perfectly clear
what is used from Delta Propagation in transactions.
After a question in the Geode user list, the following answers were received
which could be used to update the documentation:
{quote}Anil,
The tx data propagation between accessor and data store (part of the
transactions) could use delta as well; and if the transaction originator does
not host the primary copy of the data, it can also use delta to update within a
transaction.
Your understanding of client/server is correct.
Regards,
Eric{quote}
Anilkumar Gingade
Thu 4/23/2020 1:05 AM
{quote}{quote}Eric, Is that, the tx data propagation between peers/nodes (part
of the transactions) doesn't use delta?
Is it used when tx is originated in client (between client and server), but not
between peersI am trying to see where delta is used.
-Anil.{quote}{quote}
On Wed, Apr 22, 2020 at 11:58 AM Eric Shu
<[e...@pivotal.io|mailto:e...@pivotal.io]> wrote:
{quote}The transaction commits on a transaction host node (primary copy for
partitioned region, or one of the copies for replicate region), the entry
operations within this commit needs to be distributed to partitioned region's
redundant copies, or other replicates for replicate region. This distribution
can not use delta propagation.
Regards,
Eric{quote}
{quote}On Wed, Apr 22, 2020 at 11:50 AM Alberto Gomez
wrote:
{quote}Hi Eric,
What do you mean by "the transactional commit to the replicas can not use delta
propagation".
Thanks,
Alberto{quote}{quote}
{quote}{quote}*De:* Eric Shu <[e...@pivotal.io|mailto:e...@pivotal.io]>
*Enviado:* miércoles, 22 de abril de 2020 19:53
*Para:* [u...@geode.apache.org|mailto:u...@geode.apache.org]
*Asunto:* Re: Delta propagation and transactions
Hi,
Delta propagation is supported inside a transaction. I think the document is to
indicate that the distribution of the transactional commit to the replicas can
not use delta propagation.
Regards,
Eric{quote}{quote}
{quote}{quote}On Wed, Apr 22, 2020 at 9:55 AM Alberto Gomez
wrote:
{quote}Hi,
According to the Geode documentation "Geode does not propagate deltas for
Transactional commit".
Is there a reason why delta propagation cannot be supported for data updated
inside transactions?
Thanks in advance,
-Alberto G.{quote}{quote}{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7964) Upgrade mockito dependency from 2.23.0 to 3.3.3
[ https://issues.apache.org/jira/browse/GEODE-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091701#comment-17091701 ] ASF subversion and git services commented on GEODE-7964: Commit 0a1701e92dc09bcd6b79edd3b52f20ee9e9a867c in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0a1701e ] GEODE-7964: Upgrade Mockito to 3.3.3 (#4924) > Upgrade mockito dependency from 2.23.0 to 3.3.3 > --- > > Key: GEODE-7964 > URL: https://issues.apache.org/jira/browse/GEODE-7964 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Upgrade mockito dependency from 2.23.0 to 3.3.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-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=17091728#comment-17091728
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414718063
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR);
+obtainClearLockLocal(partitionedRegion.getDistributionManager().getId());
+ }
+
+ void releaseWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_UNLOCK_FOR_CLEAR);
+releaseClearLockLocal();
+ }
+
+ void clearRegion(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+clearRegionLocal(regionEvent, cacheWrite, null);
+sendLocalClearRegionMessage(regionEvent,
+ClearPartitionedRegionMessage.OperationType.OP_CLEAR);
+ }
+
+ public void clearRegionLocal(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+logger.info(" CPR.clearRegionLocal", new Exception("DEBUG"));
+// Synchronized to handle the requester departure.
+synchronized (lockForListenerAndClientNotification) {
+ if (partitionedRegion.getDataStore() != null) {
+partitionedRegion.getDataStore().lockBucketCreationForRegionClear();
+try {
+ for (BucketRegion localPrimaryBucketRegion :
partitionedRegion.getDataStore()
+ .getAllLocalPrimaryBucketRegions()) {
+localPrimaryBucketRegion.clear();
+ }
+ doAfterClear(regionEvent);
+} finally {
+
partitionedRegion.getDataStore().unLockBucketCreationForRegionClear();
+}
+ } else {
+// Non data-store with cl
[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=17091729#comment-17091729
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414718677
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR);
+obtainClearLockLocal(partitionedRegion.getDistributionManager().getId());
+ }
+
+ void releaseWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_UNLOCK_FOR_CLEAR);
+releaseClearLockLocal();
+ }
+
+ void clearRegion(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+clearRegionLocal(regionEvent, cacheWrite, null);
+sendLocalClearRegionMessage(regionEvent,
+ClearPartitionedRegionMessage.OperationType.OP_CLEAR);
+ }
+
+ public void clearRegionLocal(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+logger.info(" CPR.clearRegionLocal", new Exception("DEBUG"));
+// Synchronized to handle the requester departure.
+synchronized (lockForListenerAndClientNotification) {
+ if (partitionedRegion.getDataStore() != null) {
+partitionedRegion.getDataStore().lockBucketCreationForRegionClear();
+try {
+ for (BucketRegion localPrimaryBucketRegion :
partitionedRegion.getDataStore()
+ .getAllLocalPrimaryBucketRegions()) {
+localPrimaryBucketRegion.clear();
+ }
+ doAfterClear(regionEvent);
+} finally {
+
partitionedRegion.getDataStore().unLockBucketCreationForRegionClear();
+}
+ } else {
+// Non data-store with cl
[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=17091732#comment-17091732
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414720095
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR);
+obtainClearLockLocal(partitionedRegion.getDistributionManager().getId());
+ }
+
+ void releaseWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_UNLOCK_FOR_CLEAR);
+releaseClearLockLocal();
+ }
+
+ void clearRegion(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+clearRegionLocal(regionEvent, cacheWrite, null);
+sendLocalClearRegionMessage(regionEvent,
+ClearPartitionedRegionMessage.OperationType.OP_CLEAR);
+ }
+
+ public void clearRegionLocal(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+logger.info(" CPR.clearRegionLocal", new Exception("DEBUG"));
+// Synchronized to handle the requester departure.
+synchronized (lockForListenerAndClientNotification) {
+ if (partitionedRegion.getDataStore() != null) {
+partitionedRegion.getDataStore().lockBucketCreationForRegionClear();
+try {
+ for (BucketRegion localPrimaryBucketRegion :
partitionedRegion.getDataStore()
+ .getAllLocalPrimaryBucketRegions()) {
+localPrimaryBucketRegion.clear();
+ }
+ doAfterClear(regionEvent);
+} finally {
+
partitionedRegion.getDataStore().unLockBucketCreationForRegionClear();
+}
+ } else {
+// Non data-store with cl
[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=17091753#comment-17091753 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag commented on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-619138208 > > 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. We are in the process of open-sourcing the tests. More details incoming. Simple root cause is: When there is a newer version gemfire with older version, the aysnc listener is blocked waiting on the index repository to be created, but the queues continue to get filled up and ultimately result in overflow. Also, you can see that I have another pull request over your commit [https://github.com/apache/geode/pull/4826] which solves this problem. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091755#comment-17091755 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag commented on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-619140086 @mkevo It is nearly complete, but the tests may be exposing another issue with the geode code base (un-related to lucene) which I am trying to fix, but I was unable to get to (other commitments) .. I will try to get it fixed shortly. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091764#comment-17091764 ] ASF GitHub Bot commented on GEODE-7309: --- nabarunnag edited a comment on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-619138208 > > 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. We are in the process of open-sourcing the tests. More details incoming. Simple root cause is: When there is a newer version gemfire with older version, the aysnc listener is blocked waiting on the index repository to be created, but the queues continue to get filled up and ultimately result in overflow. I will have a PR up soon which solves these issues. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-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=17091765#comment-17091765
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414720095
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR);
+obtainClearLockLocal(partitionedRegion.getDistributionManager().getId());
+ }
+
+ void releaseWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_UNLOCK_FOR_CLEAR);
+releaseClearLockLocal();
+ }
+
+ void clearRegion(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+clearRegionLocal(regionEvent, cacheWrite, null);
+sendLocalClearRegionMessage(regionEvent,
+ClearPartitionedRegionMessage.OperationType.OP_CLEAR);
+ }
+
+ public void clearRegionLocal(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+logger.info(" CPR.clearRegionLocal", new Exception("DEBUG"));
+// Synchronized to handle the requester departure.
+synchronized (lockForListenerAndClientNotification) {
+ if (partitionedRegion.getDataStore() != null) {
+partitionedRegion.getDataStore().lockBucketCreationForRegionClear();
+try {
+ for (BucketRegion localPrimaryBucketRegion :
partitionedRegion.getDataStore()
+ .getAllLocalPrimaryBucketRegions()) {
+localPrimaryBucketRegion.clear();
+ }
+ doAfterClear(regionEvent);
+} finally {
+
partitionedRegion.getDataStore().unLockBucketCreationForRegionClear();
+}
+ } else {
+// Non data-store with cl
[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=17091775#comment-17091775
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414745741
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
Review comment:
Since the message is to let other member lock rvv and prepare for clear.
The "sendLocalClearRegionMessage" is better to be rename to
sendLockForClearPRMessage
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-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=17091795#comment-17091795
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414754247
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
Review comment:
sendLocalClearRegionMessage() created a message whose operation is
ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR, but the event's
operation
is Operation.REGION_LOCAL_CLEAR. It's confusing here. Actually this message
is not "local clear", it's only "lock for pr clear (locally)".
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 w
[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=17091800#comment-17091800
]
ASF GitHub Bot commented on GEODE-7678:
---
gesterzhou commented on a change in pull request #4987:
URL: https://github.com/apache/geode/pull/4987#discussion_r414757960
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/ClearPartitionedRegion.java
##
@@ -0,0 +1,347 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Iterator;
+
+import org.apache.logging.log4j.Logger;
+
+import org.apache.geode.CancelException;
+import org.apache.geode.cache.Operation;
+import org.apache.geode.cache.partition.PartitionRegionHelper;
+import org.apache.geode.distributed.internal.DistributionManager;
+import org.apache.geode.distributed.internal.MembershipListener;
+import org.apache.geode.distributed.internal.ReplyException;
+import
org.apache.geode.distributed.internal.membership.InternalDistributedMember;
+import org.apache.geode.internal.cache.versions.RegionVersionVector;
+import org.apache.geode.logging.internal.log4j.api.LogService;
+
+public class ClearPartitionedRegion {
+
+ private static final Logger logger = LogService.getLogger();
+
+ private final PartitionedRegion partitionedRegion;
+
+ private LockForListenerAndClientNotification
lockForListenerAndClientNotification =
+ new LockForListenerAndClientNotification();
+
+ public ClearPartitionedRegion(PartitionedRegion partitionedRegion) {
+this.partitionedRegion = partitionedRegion;
+partitionedRegion.getDistributionManager()
+.addMembershipListener(new ClearPartitionedRegionListener());
+ }
+
+ public boolean isLockedForListenerAndClientNotification() {
+return lockForListenerAndClientNotification.isLocked();
+ }
+
+ void acquireDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().lock(clearLock, -1,
-1);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+ throw e;
+}
+ }
+
+ void releaseDistributedClearLock(String clearLock) {
+try {
+ partitionedRegion.getPartitionedRegionLockService().unlock(clearLock);
+} catch (IllegalStateException e) {
+ partitionedRegion.lockCheckReadiness();
+} catch (Exception ex) {
+ logger.warn("Caught exception while unlocking clear distributed lock",
ex.getMessage());
+}
+ }
+
+ void obtainWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_LOCK_FOR_CLEAR);
+obtainClearLockLocal(partitionedRegion.getDistributionManager().getId());
+ }
+
+ void releaseWriteLockForClear(RegionEventImpl event) {
+sendLocalClearRegionMessage(event,
+ClearPartitionedRegionMessage.OperationType.OP_UNLOCK_FOR_CLEAR);
+releaseClearLockLocal();
+ }
+
+ void clearRegion(RegionEventImpl regionEvent, boolean cacheWrite,
+ RegionVersionVector vector) {
+clearRegionLocal(regionEvent, cacheWrite, null);
+sendLocalClearRegionMessage(regionEvent,
Review comment:
sendLocalClearRegionMessage() method is shared by all the 3 mesgs:
obtainWriteLockForClear, clearRegion, releaseWriteLockForClear. So it's better
to rename it to sendPRClearOperationMessage, or other generic name. It should
not be "LocalClear".
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
> Component
[jira] [Created] (GEODE-8020) buffer corruption in SSL communications
Bruce J Schuchardt created GEODE-8020:
-
Summary: buffer corruption in SSL communications
Key: GEODE-8020
URL: https://issues.apache.org/jira/browse/GEODE-8020
Project: Geode
Issue Type: Bug
Components: messaging
Reporter: Bruce J Schuchardt
When running an application with SSL enabled I ran into a hang with a lost
message. The sender had a 15 second ack-wait warning pointing to another
server in the cluster. That server had this in its log file at the time the
message would have been processed:
{noformat}
[info 2020/04/21 11:22:39.437 PDT :41003
unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
reader@2580db5f io exception for
rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
1.10.0)
javax.net.ssl.SSLException: bad record MAC
at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
at
org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
at
org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.crypto.BadPaddingException: bad record MAC
at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
at
sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
... 10 more
{noformat}
I bisected to see when this problem was introduced and found it was this commit:
{noformat}
commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
Date: Fri Nov 1 20:28:57 2019 +0100
GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
- Fixed use of Direct and Non-Direct buffers
{noformat}
That commit modified the NioSSLEngine to use a "direct" byte buffer instead of
a heap byte buffer. If I revert that one part of the PR the test works okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8020:
-
Assignee: Bruce J Schuchardt
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8020:
--
Component/s: membership
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-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=17091822#comment-17091822 ] ASF subversion and git services commented on GEODE-7851: Commit 2999414d6004b7725fd9652f75dbfdb549a2544d in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2999414 ] GEODE-7851: Pulse refreshes expired access tokens (#4977) If a user's access token expires, Pulse attempts to refresh it. If the refresh fails, Pulse logs the user out and redirects the browser to /pulse/clusterLogout. Changes in Repository: - When OAuth is configured, before returning the user's cluster, getCluster() checks whether the user's access token has expired. - If the access token has expired, the repository attempts to refresh it. If the refresh succeeds, the repository reconnects the user's cluster to JMX and returns it. - If the refresh fails, the repository disconnects the user's cluster from JMX, removes the cluster from the repository, and throws an authentication or authorization exception. Changes in PulseController: - If the service call throws an authentication or authorization exception, PulseController. getPulseUpdate() returns a 401 status. Changes in pulsescript/common.js: - If a Pulse ajax call returns a 401 status, ajaxPost() redirects the browser to /pulse/clusterLogout to log the user out and request re-authorization. Co-authored-by: Joris Melchior Co-authored-by: Dale Emery Co-authored-by: Jinmei Liao Co-authored-by: Kirk Lund Co-authored-by: Joris Melchior Co-authored-by: Jinmei Liao > 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] [Updated] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-7851: -- Fix Version/s: 1.13.0 > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Fix For: 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-7851. --- Resolution: Done > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Fix For: 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-7851. - > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Fix For: 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
Benjamin P Ross created GEODE-8021: -- Summary: CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket Key: GEODE-8021 URL: https://issues.apache.org/jira/browse/GEODE-8021 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross org.apache.geode.internal.tcp.CloseConnectionTest > sharedSenderShouldRecoverFromClosedSocket FAILED 16:25:33 org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in VM 1 running on Host 0f261f07755e with 4 VMs 16:25:33 at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) 16:25:33 at org.apache.geode.test.dunit.VM.invoke(VM.java:437) 16:25:33 at org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102) 16:25:33 16:25:33 Caused by: 16:25:33 org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> 16:25:33 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 16:25:33 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 16:25:33 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 16:25:33 at org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109) 18:30:47 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-8021:
---
Description:
{code:java}
org.apache.geode.internal.tcp.CloseConnectionTest >
sharedSenderShouldRecoverFromClosedSocket FAILED
16:25:33org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in
VM 1 running on Host 0f261f07755e with 4 VMs
16:25:33at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
16:25:33at
org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
16:25:33
16:25:33Caused by:
16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
16:25:33at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
16:25:33at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
16:25:33at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
16:25:33at
org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
18:30:47
{code}
was:org.apache.geode.internal.tcp.CloseConnectionTest >
sharedSenderShouldRecoverFromClosedSocket FAILED 16:25:33
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in
VM 1 running on Host 0f261f07755e with 4 VMs 16:25:33 at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) 16:25:33 at
org.apache.geode.test.dunit.VM.invoke(VM.java:437) 16:25:33 at
org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
16:25:33 16:25:33 Caused by: 16:25:33 org.junit.ComparisonFailure:
expected:<[tru]e> but was:<[fals]e> 16:25:33 at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 16:25:33
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
16:25:33 at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
16:25:33 at
org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
18:30:47
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-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=17091905#comment-17091905
]
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_r414861362
##
File path:
geode-gfsh/src/test/java/org/apache/geode/management/internal/cli/commands/ClearCommandTest.java
##
@@ -0,0 +1,93 @@
+package org.apache.geode.management.internal.cli.commands;
+
+import static
org.apache.geode.management.internal.i18n.CliStrings.CLEAR_REGION;
+import static
org.apache.geode.management.internal.i18n.CliStrings.CLEAR_REGION_REGION_NAME;
+import static
org.apache.geode.management.internal.cli.commands.ClearCommand.REGION_NOT_FOUND;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.mockito.Mockito.doNothing;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.when;
+
+import java.util.HashSet;
+import java.util.Set;
+
+import org.junit.Before;
+import org.junit.ClassRule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.management.internal.cli.domain.DataCommandRequest;
+import org.apache.geode.management.internal.cli.domain.DataCommandResult;
+import org.apache.geode.management.internal.cli.functions.DataCommandFunction;
+import org.apache.geode.management.internal.cli.result.model.ResultModel;
+import org.apache.geode.test.junit.rules.GfshParserRule;
+
+public class ClearCommandTest {
Review comment:
This feels like more of an integration test as it's currently written,
since it's not directly testing the ClearCommand class but rather how that
class is used by gfsh. Instead of using `gfsh.executeAndAssertThat`, it might
better to call `ClearCommand.clear()` directly and assert on the returned
`ResultModel`.
It would also be good to verify that `callFunctionForRegion()` and
`clearfn.remove()` are called with the expected/correct arguments, rater than
just asserting the success/failure of the command, since otherwise the last two
test cases end up being indistinguishable in terms of what they're asserting
and the actual difference in behaviour between the two code paths isn't being
verified.
##
File path:
geode-gfsh/src/test/java/org/apache/geode/management/internal/cli/commands/ClearCommandTest.java
##
@@ -0,0 +1,93 @@
+package org.apache.geode.management.internal.cli.commands;
+
+import static
org.apache.geode.management.internal.i18n.CliStrings.CLEAR_REGION;
+import static
org.apache.geode.management.internal.i18n.CliStrings.CLEAR_REGION_REGION_NAME;
+import static
org.apache.geode.management.internal.cli.commands.ClearCommand.REGION_NOT_FOUND;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.ArgumentMatchers.anyString;
+import static org.mockito.Mockito.doNothing;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.when;
+
+import java.util.HashSet;
+import java.util.Set;
+
+import org.junit.Before;
+import org.junit.ClassRule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.Region;
+import org.apache.geode.distributed.DistributedMember;
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.management.internal.cli.domain.DataCommandRequest;
+import org.apache.geode.management.internal.cli.domain.DataCommandResult;
+import org.apache.geode.management.internal.cli.functions.DataCommandFunction;
+import org.apache.geode.management.internal.cli.result.model.ResultModel;
+import org.apache.geode.test.junit.rules.GfshParserRule;
+
+public class ClearCommandTest {
+
+ @ClassRule
+ public static GfshParserRule gfsh = new GfshParserRule();
+
+ static final String regionName = "regionName";
+ static final String success = "SUCCESS";
+
+ InternalCache cache;
+ ClearCommand command;
+ Region region;
+ Set membersList;
+ DistributedMember member;
+ DataCommandResult dataResult;
+
+ @Before
+ public void setup() {
+cache = mock(InternalCache.class);
+command = spy(new ClearCommand());
+region = mock(Region.class);
+dataResult = mock(DataCommandResult.class);
+
+membersList = new HashSet();
Review comment:
It's not necessary to specify the `DistributedMember` here, since it's
implicit in the declaration of the `membersList
[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=17091916#comment-17091916 ] ASF GitHub Bot commented on GEODE-7851: --- demery-pivotal opened a new pull request #4992: URL: https://github.com/apache/geode/pull/4992 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 > Fix For: 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8022) packer cannot create new windows images
Robert Houghton created GEODE-8022: -- Summary: packer cannot create new windows images Key: GEODE-8022 URL: https://issues.apache.org/jira/browse/GEODE-8022 Project: Geode Issue Type: Bug Components: ci Reporter: Robert Houghton Continuous tcp timeouts while Packer tries to connect to google-compute windows instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8022) packer cannot create new windows images
[ https://issues.apache.org/jira/browse/GEODE-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091930#comment-17091930 ] ASF GitHub Bot commented on GEODE-8022: --- rhoughton-pivot opened a new pull request #4993: URL: https://github.com/apache/geode/pull/4993 DRY the packer creation scripts. Tested by pinning a working windows image ID. Signed-off-by: Sean Goller 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 > packer cannot create new windows images > --- > > Key: GEODE-8022 > URL: https://issues.apache.org/jira/browse/GEODE-8022 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Priority: Major > > Continuous tcp timeouts while Packer tries to connect to google-compute > windows instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091952#comment-17091952
]
ASF subversion and git services commented on GEODE-8020:
Commit a0b7880c978c23fd13da31a7161c1ffec2d9285e in geode's branch
refs/heads/feature/GEODE-8020 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a0b7880 ]
GEODE-8020: buffer corruption in SSL communications
revert change in GEODE-6661 that made NioSslEngine use a direct buffer.
This class is not designed to share its buffer with a pool in
BufferPool. Connection is also modified to use a heap buffer for
reading encrypted SSL packets for consistency. New tests ensure that
these buffers are the correct type when using SSL or plain sockets.
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091954#comment-17091954
]
ASF GitHub Bot commented on GEODE-8020:
---
bschuchardt opened a new pull request #4994:
URL: https://github.com/apache/geode/pull/4994
revert change in GEODE-6661 that made NioSslEngine use a direct buffer.
This class is not designed to share its buffer with a pool in
BufferPool. Connection is also modified to use a heap buffer for
reading encrypted SSL packets for consistency. New tests ensure that
these buffers are the correct type when using SSL or plain sockets.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] 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
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the
[jira] [Commented] (GEODE-6661) NioSslEngine has some problems in its ByteBuffer management
[ https://issues.apache.org/jira/browse/GEODE-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091953#comment-17091953 ] ASF subversion and git services commented on GEODE-6661: Commit a0b7880c978c23fd13da31a7161c1ffec2d9285e in geode's branch refs/heads/feature/GEODE-8020 from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a0b7880 ] GEODE-8020: buffer corruption in SSL communications revert change in GEODE-6661 that made NioSslEngine use a direct buffer. This class is not designed to share its buffer with a pool in BufferPool. Connection is also modified to use a heap buffer for reading encrypted SSL packets for consistency. New tests ensure that these buffers are the correct type when using SSL or plain sockets. > NioSslEngine has some problems in its ByteBuffer management > --- > > Key: GEODE-6661 > URL: https://issues.apache.org/jira/browse/GEODE-6661 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Darrel Schneider >Assignee: Bruce J Schuchardt >Priority: Major > Labels: performance > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > the NioSslEngine appears to have some problems with how it manages ByteBuffer > instances, > # It has a "handshakeBuffer" instance variable and code that will > conditionally create it but higher level code always passes in a non-null > inputBuffer. It should just be changed to require an outside buffer. Also no > need for an instance variable since "handshakeBuffer" is only used by a > single method. It can just be passed in to it. > # The "myNetData" and "peerAppData" are both created as heap ByteBuffer > instances in the constructor. But if they ever need to be resized it does it > by calling Buffers.expandWriteBufferIfNeeded which will return the original > heap ByteBuffer to the queue of buffers that should always be direct byte > buffers. And now the one used by NioSslEngine will be direct instead of heap. > This will also cause the stats that Buffers has to be wrong because we return > a buffer to it that we did not allocate from it. > # From a performance standpoint, we want to also have the buffer that we > directly write to a socket channel, or fill by reading from a socket channel, > be a direct byte buffer. Other byte buffers should not be direct. So normally > the ByteBuffer we serialize an outgoing message into is a direct ByteBuffer > because it will be handed to the socket channel for the message write. But in > the case of the NioSslEngine we would want that first buffer to be a > non-direct, heap ByteBuffer. It ends up being passed to NioSslEngine.wrap > which copies it into "myNetData". The encrypted data in "myNetData" in turn > is written to the socket channel so it is the one that should be a direct > ByteBuffer. For reading it is just the opposite. We read encrypted data from > the socket channel into what should be direct byte buffer (and it currently > is because it is allocated with Buffers). But then it is passed to > NioSslEngine.unwrap which will copy (and decrypt) what is in it into the > "peerAppData". So "peerAppData" should be kept a heap ByteBuffer. You can > always get away with using either type of ByteBuffer. It is simply a > performance issue. What happens at a lower level in the jdk with a heap > ByteBuffer being used with a socket channel is that it eventually just copies > it into a direct ByteBuffer and then uses it. That extra copy can hurt > performance and in the past we had trouble with the jdk caching of direct > ByteBuffers not reusing as well as ours and running out of direct memory. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8020) buffer corruption in SSL communications
[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17091964#comment-17091964
]
ASF GitHub Bot commented on GEODE-8020:
---
pivotal-jbarrett commented on a change in pull request #4994:
URL: https://github.com/apache/geode/pull/4994#discussion_r414907721
##
File path:
geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
##
@@ -1662,8 +1662,8 @@ private void readMessages() {
} catch (IOException e) {
// "Socket closed" check needed for Solaris jdk 1.4.2_08
if (!isSocketClosed() && !"Socket
closed".equalsIgnoreCase(e.getMessage())) {
-if (logger.isDebugEnabled() && !isIgnorableIOException(e)) {
- logger.debug("{} io exception for {}", p2pReaderName(), this, e);
+if (logger.isInfoEnabled() && !isIgnorableIOException(e)) {
Review comment:
Is it intentional to increase the verbosity of this log message?
##
File path:
geode-core/src/main/java/org/apache/geode/internal/tcp/Connection.java
##
@@ -1763,9 +1763,13 @@ private static boolean isIgnorableIOException(Exception
e) {
}
msg = msg.toLowerCase();
-return msg.contains("forcibly closed")
-|| msg.contains("reset by peer")
-|| msg.contains("connection reset");
+
+if (e instanceof SSLException && msg.contains("status = closed")) {
Review comment:
The commit message references reverting the direct buffer changes. Is
this change intentional because it doesn't look like part of the reverted
commit?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> buffer corruption in SSL communications
> ---
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599):41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(
[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=17091972#comment-17091972 ] ASF subversion and git services commented on GEODE-7851: Commit 6ffbab0d484811baa009b5bb72896b9f42cce21f in geode's branch refs/heads/support/1.12 from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6ffbab0 ] GEODE-7851: Add slf4j implementation to Pulse (#4992) 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 > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Fix For: 1.13.0 > > Time Spent: 12h 10m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8022) packer cannot create new windows images
[ https://issues.apache.org/jira/browse/GEODE-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092025#comment-17092025 ] ASF subversion and git services commented on GEODE-8022: Commit 0aae6cbce71a9c4e4ca4b93589c0fbe164d8ac99 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0aae6cb ] GEODE-8022: Fix windows image build via pinning. (#4993) DRY the packer creation scripts. Tested by pinning a working windows image ID. Signed-off-by: Sean Goller > packer cannot create new windows images > --- > > Key: GEODE-8022 > URL: https://issues.apache.org/jira/browse/GEODE-8022 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Priority: Major > > Continuous tcp timeouts while Packer tries to connect to google-compute > windows instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8023) add old version to support branches too
Owen Nichols created GEODE-8023: --- Summary: add old version to support branches too Key: GEODE-8023 URL: https://issues.apache.org/jira/browse/GEODE-8023 Project: Geode Issue Type: Bug Components: release Reporter: Owen Nichols Need to add the old version on the support branch too now, not just develop (e.g. as soon as 1.12.0 was released, the support branch became 1.12.1 so 1.12.0 is an "old" version for both develop and support/1.12) need to update release scripts before next release so this will happen automatically -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8023) add old version to support branches too
[ https://issues.apache.org/jira/browse/GEODE-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-8023: --- Assignee: Owen Nichols > add old version to support branches too > --- > > Key: GEODE-8023 > URL: https://issues.apache.org/jira/browse/GEODE-8023 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > Need to add the old version on the support branch too now, not just develop > (e.g. as soon as 1.12.0 was released, the support branch became 1.12.1 so > 1.12.0 is an "old" version for both develop and support/1.12) > need to update release scripts before next release so this will happen > automatically -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8023) add old version to support branches too
[ https://issues.apache.org/jira/browse/GEODE-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092029#comment-17092029 ] ASF GitHub Bot commented on GEODE-8023: --- onichols-pivotal opened a new pull request #4995: URL: https://github.com/apache/geode/pull/4995 Need to add the old version on the support branch too now, not just develop (e.g. as soon as 1.12.0 was released, the support branch became 1.12.1 so 1.12.0 is an "old" version for both develop and support/1.12) This was a non-issue before when we had release branches that were discarded after release. This PR updates the release scripts so this will happen automatically. 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 > add old version to support branches too > --- > > Key: GEODE-8023 > URL: https://issues.apache.org/jira/browse/GEODE-8023 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > Need to add the old version on the support branch too now, not just develop > (e.g. as soon as 1.12.0 was released, the support branch became 1.12.1 so > 1.12.0 is an "old" version for both develop and support/1.12) > need to update release scripts before next release so this will happen > automatically -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7999) snapshots not available for support branches
[ https://issues.apache.org/jira/browse/GEODE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092040#comment-17092040 ] ASF GitHub Bot commented on GEODE-7999: --- onichols-pivotal opened a new pull request #4996: URL: https://github.com/apache/geode/pull/4996 Using maven to fetch org.apache.geode:geode-core:1.12.0-SNAPSHOT currently returns an artifact from Feb 5 -- the last day develop was 1.12. Now that we have long-lived support branches, we should continue publishing to the snapshot repo from those support branches as well. This PR changes the release scripts to not remove -SNAPSHOT when cutting a support branch and changes the conditionals in the pipeline jinja template to keep the PublishArtifacts job on 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 > snapshots not available for support branches > > > Key: GEODE-7999 > URL: https://issues.apache.org/jira/browse/GEODE-7999 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Owen Nichols >Priority: Major > > Using maven to fetch org.apache.geode:geode-core:1.12.0-SNAPSHOT currently > returns an artifact from Feb 5 -- the last day develop was 1.12. Now that we > have long-lived support branches, we should continue publishing to the > snapshot repo from those support branches as well. > Changes needed: > change the release scripts to not remove -SNAPSHOT when cutting a support > branch > change the conditionals in the pipeline jinja template to keep the > PublishArtifacts job on support branches. > backport these changes to support/1.12 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8023) add old version to support branches too
[ https://issues.apache.org/jira/browse/GEODE-8023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17092047#comment-17092047 ] ASF subversion and git services commented on GEODE-8023: Commit 326f228c836aee8982d5581d36eba11f0dadc151 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=326f228 ] GEODE-8023: add old version on support branch too (#4995) > add old version to support branches too > --- > > Key: GEODE-8023 > URL: https://issues.apache.org/jira/browse/GEODE-8023 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > Need to add the old version on the support branch too now, not just develop > (e.g. as soon as 1.12.0 was released, the support branch became 1.12.1 so > 1.12.0 is an "old" version for both develop and support/1.12) > need to update release scripts before next release so this will happen > automatically -- This message was sent by Atlassian Jira (v8.3.4#803005)
