[jira] [Commented] (GEODE-7252) IncrementalBackupDistributedTest.testMissingMemberInBaseline fails suspect string java.io.IOException: No backup currently in progress
[
https://issues.apache.org/jira/browse/GEODE-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946358#comment-16946358
]
Barrett Oglesby commented on GEODE-7252:
This issue occurred again in build 1158:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1158
> IncrementalBackupDistributedTest.testMissingMemberInBaseline fails suspect
> string java.io.IOException: No backup currently in progress
> --
>
> Key: GEODE-7252
> URL: https://issues.apache.org/jira/browse/GEODE-7252
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Priority: Major
>
> IncrementalBackupDistributedTest.testMissingMemberInBaseline intermittently
> fails with suspect string {{java.io.IOException: No backup currently in
> progress}}.
> {noformat}
> org.apache.geode.internal.cache.backup.IncrementalBackupDistributedTest >
> testMissingMemberInBaseline FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1970
> [error 2019/09/27 21:50:39.144 GMT tid=79]
> Error processing request class
> org.apache.geode.internal.cache.backup.FinishBackupRequest.
> java.io.IOException: No backup currently in progress
> at
> org.apache.geode.internal.cache.backup.BackupService.doBackup(BackupService.java:69)
> at
> org.apache.geode.internal.cache.backup.FinishBackup.run(FinishBackup.java:36)
> at
> org.apache.geode.internal.cache.backup.FinishBackupRequest.createResponse(FinishBackupRequest.java:56)
> at
> org.apache.geode.internal.admin.remote.CliLegacyMessage.process(CliLegacyMessage.java:37)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:436)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:473)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:404)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7276) CI failure: Benchmark PartitionedPutBenchmark analysis failed
[
https://issues.apache.org/jira/browse/GEODE-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946354#comment-16946354
]
Barrett Oglesby commented on GEODE-7276:
The occurred again in build 617:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/617
> CI failure: Benchmark PartitionedPutBenchmark analysis failed
> -
>
> Key: GEODE-7276
> URL: https://issues.apache.org/jira/browse/GEODE-7276
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Reporter: Barrett Oglesby
>Priority: Major
>
> Benchmark test 615
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/615)
> failed with:
> {noformat}
> BENCHMARK FAILED: org.apache.geode.benchmark.tests.PartitionedPutBenchmark
> missing result file.
> BENCHMARK FAILED: org.apache.geode.benchmark.tests.PartitionedPutBenchmark
> missing result file.
> {noformat}
> The Analyzer is attempting to compare the test with the baseline and not
> finding a
> {noformat}
> for (BenchmarkRunResult.ProbeResult probeResult :
> benchmarkResult.probeResults) {
> if (isNaN(probeResult.baseline) || isNaN(probeResult.test)) {
> errorMessage.append("BENCHMARK FAILED: ").append(benchmarkResult.name)
> .append(" missing result file.\n");
> {noformat}
> The output for the PartitionedPutBenchmark is:
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedPutBenchmark
> average ops/second Baseline:204975.67 Test: NaN
> Difference:NaN%
>ops/second standard error Baseline: 308.71 Test: NaN
> Difference:NaN%
>ops/second standard deviation Baseline: 5338.09 Test:-0.00
> Difference: -100.0%
> YS 99th percentile latency Baseline: 3808.00 Test: 3510.00
> Difference: -7.8%
> median latency Baseline:575487.00 Test:568319.00
> Difference: -1.2%
> 90th percentile latency Baseline: 4476927.00 Test: 4378623.00
> Difference: -2.2%
> 99th percentile latency Baseline: 9379839.00 Test: 9543679.00
> Difference: +1.7%
>99.9th percentile latency Baseline: 51118079.00 Test: 52002815.00
> Difference: +1.7%
> average latency Baseline: 1754859.17 Test: 1757899.99
> Difference: +0.2%
> latency standard deviation Baseline: 3494292.88 Test: 5794614.66
> Difference: +65.8%
> latency standard error Baseline: 445.63 Test: 2335.52
> Difference: +424.1%
> {noformat}
> It would be nice if the BENCHMARK FAILED message printed the
> probeResult.description, but I guess the two BENCHMARK FAILED messages
> correspond to average ops/second and ops/second standard error since those
> are the two NAN values.
> There are several RuntimeException in both the baseline and branch client.log
> files, but since both of the files contain those, it doesn't look related.
> {noformat}
> [RMI TCP Connection(1)-172.31.46.146] WARN org.reflections.Reflections -
> could not create Dir using directory from url
> file:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so.
> skipping.
> java.lang.RuntimeException: cannot use dir
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so
> [RMI TCP Connection(1)-172.31.46.146] WARN org.reflections.Reflections -
> could not create Vfs.Dir from url. ignoring the exception and continuing
> org.reflections.ReflectionsException: could not create Vfs.Dir from url, no
> matching UrlType was found
> [file:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so]
> either use fromURL(final URL url, final List urlTypes) or use the
> static setDefaultURLTypes(final List urlTypes) or
> addDefaultURLTypes(UrlType urlType) with your specialized UrlType.
> {noformat}
> On the other hand, the branch client.log file contains this exception, but
> unfortunately, the servers look to be configured with warn log level, so its
> hard to tell why this exception occurred, and if its even relevant.
> {noformat}
> Finishing main test [ts=1570353668642, date=Sun Oct 06 09:21:08 UTC 2019]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> org.apache.geode.cache.client.ServerConnectivityException: Pool unexpected
> socket timed out on client connection=Pooled Connection to
> ip-172-31-42-223.us-west-2.compute.internal:46801: Connection[DESTROYED]
> attempt=2). Server unreachable: could not connect after 2 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
>
[jira] [Commented] (GEODE-7277) CI failure: DestroyLuceneIndexCommandsDUnitTest > testDestroyIndexesWithOneIndexAndRegionInOneMember failed with RegionDestroyedException suspicious string
[
https://issues.apache.org/jira/browse/GEODE-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946353#comment-16946353
]
Barrett Oglesby commented on GEODE-7277:
Here is some logging the monitoringRegion being destroying as a result of the
cache closing:
{noformat}
[warn 2019/10/07 17:03:27.717 PDT tid=0x66] XXX
LocalRegion.basicDestroyRegion region=/_monitoringRegion_192.168.1.441001
java.lang.Exception
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6132)
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6127)
at
org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2250)
at
org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:452)
at
org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
at
org.apache.geode.management.internal.FederatingManager.stopManagingActivity(FederatingManager.java:147)
at
org.apache.geode.management.internal.FederatingManager.stopManager(FederatingManager.java:135)
at
org.apache.geode.management.internal.SystemManagementService.close(SystemManagementService.java:243)
at
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheRemoval(ManagementAdapter.java:745)
at
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:131)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2052)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:599)
at
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2098)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1503)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1182)
at
org.apache.geode.management.internal.beans.MemberMBeanBridge.lambda$shutDownMember$0(MemberMBeanBridge.java:810)
at java.base/java.lang.Thread.run(Thread.java:834)
[info 2019/10/07 17:03:27.734 PDT tid=0x66] GemFireCache[id =
765950170; isClosing = true; isShutDownAll = false; created = Mon Oct 07
17:01:47 PDT 2019; server = false; copyOnRead = false; lockLease = 120;
lockTimeout = 60]: Now closing.
{noformat}
Here is some logging showing the monitoringRegion being destroyed as a result
of the member departing:
{noformat}
[info 2019/10/07 17:18:51.964 PDT
tid=0x5a] Member at 192.168.1.4(server-1:35877):41001 gracefully left the
distributed cache: shutdown message received
[warn 2019/10/07 17:18:51.965 PDT tid=0x1e] XXX
FederatingManager.removeMember member=192.168.1.4(server-1:35877):41001
java.lang.Exception
at
org.apache.geode.management.internal.FederatingManager.removeMember(FederatingManager.java:188)
at
org.apache.geode.management.internal.ManagementMembershipListener.memberDeparted(ManagementMembershipListener.java:57)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:3543)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:3473)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:3462)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2023)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$400(ClusterDistributionManager.java:114)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2055)
at java.base/java.lang.Thread.run(Thread.java:834)
[warn 2019/10/07 17:18:51.966 PDT tid=0x62] XXX
RemoveMemberTask.run member=192.168.1.4(server-1:35877):41001
[warn 2019/10/07 17:18:51.967 PDT tid=0x62] XXX
LocalRegion.basicDestroyRegion region=/_monitoringRegion_192.168.1.441001
java.lang.Exception
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6132)
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6127)
at
org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2250)
at
[jira] [Created] (GEODE-7277) CI failure: DestroyLuceneIndexCommandsDUnitTest > testDestroyIndexesWithOneIndexAndRegionInOneMember failed with RegionDestroyedException suspicious string
Barrett Oglesby created GEODE-7277:
--
Summary: CI failure: DestroyLuceneIndexCommandsDUnitTest >
testDestroyIndexesWithOneIndexAndRegionInOneMember failed with
RegionDestroyedException suspicious string
Key: GEODE-7277
URL: https://issues.apache.org/jira/browse/GEODE-7277
Project: Geode
Issue Type: Bug
Components: jmx
Reporter: Barrett Oglesby
DistributedTestOpenJDK11 #1147
(https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1147)
failed with this RegionDestroyedException suspicious string:
{noformat}
org.apache.geode.cache.lucene.internal.cli.DestroyLuceneIndexCommandsDUnitTest
> testDestroyIndexesWithOneIndexAndRegionInOneMember FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2012
[fatal 2019/10/07 21:18:02.334 GMT tid=845] Uncaught
exception in thread Thread[FederatingManager4,5,RMI Runtime]
org.apache.geode.cache.RegionDestroyedException:
org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_172.17.0.1041002';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE]
at
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157)
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128)
at
org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251)
at
org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:452)
at
org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
at
org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67)
at
org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
This failure has nothing to do with Lucene.
Some analysis shows that stopping a member and stopping the locator nearly
simultaneously can cause this RegionDestroyedException.
The test output shows:
The locator starts:
{noformat}
[vm0] [info 2019/10/07 21:17:55.174 GMT
tid=0x22] Starting DistributionManager
172.17.0.10(locator-0:87:locator):41000. (took 26 ms)
{noformat}
Server1 starts and _monitoringRegion_172.17.0.1041001 is created for it in
the locator:
{noformat}
[vm1] [info 2019/10/07 21:17:59.681 GMT
tid=0x22] Starting DistributionManager 172.17.0.10(server-1:95):41001.
(took 405 ms)
[vm0] [info 2019/10/07 21:17:59.684 GMT tid=0x332]
Initializing region _monitoringRegion_172.17.0.1041001
[vm0] [info 2019/10/07 21:17:59.694 GMT tid=0x332]
Initialization of region _monitoringRegion_172.17.0.1041001 completed
{noformat}
Server2 starts and _monitoringRegion_172.17.0.1041002 is created for it in
the locator:
{noformat}
[vm2] [info 2019/10/07 21:18:00.379 GMT
tid=0x22] Starting DistributionManager 172.17.0.10(server-2:104):41002.
(took 361 ms)
[vm0] [info 2019/10/07 21:18:00.379 GMT tid=0x33c]
Initializing region _monitoringRegion_172.17.0.1041002
[vm0] [info 2019/10/07 21:18:00.424 GMT tid=0x33c]
Initialization of region _monitoringRegion_172.17.0.1041002 completed
{noformat}
Server2 shuts down:
{noformat}
[vm2] [info 2019/10/07 21:18:02.007 GMT
tid=0x22] Shutting down DistributionManager
172.17.0.10(server-2:104):41002.
[vm2] [info 2019/10/07 21:18:02.127 GMT
tid=0x22] Marking DistributionManager 172.17.0.10(server-2:104):41002 as
closed.
{noformat}
Server1 shuts down:
{noformat}
[vm1] [info 2019/10/07 21:18:02.189 GMT
tid=0x22] Shutting down DistributionManager 172.17.0.10(server-1:95):41001.
[vm1] [info 2019/10/07 21:18:02.309 GMT
tid=0x22] Marking DistributionManager 172.17.0.10(server-1:95):41001 as
closed.
{noformat}
The locator logs server1 leaving the distributed system:
{noformat}
[vm0] [info 2019/10/07 21:18:02.316 GMT tid=0x331]
Member at 172.17.0.10(server-1:95):41001 gracefully left the distributed
cache: departed membership view
{noformat}
Then, the locator starts to shut down:
{noformat}
[vm0] [info 2019/10/07 21:18:02.322 GMT
tid=0x22] Stopping Distribution Locator on 7f8e3ffa7dc2[34127]
{noformat}
Then, the locator logs
[jira] [Resolved] (GEODE-7151) Remove some not used test classes
[ https://issues.apache.org/jira/browse/GEODE-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-7151. Fix Version/s: 1.11.0 Resolution: Fixed > Remove some not used test classes > - > > Key: GEODE-7151 > URL: https://issues.apache.org/jira/browse/GEODE-7151 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Trivial > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Following classes are not used and can be removed from the code: > * geode-core/src/test/java/com/examples/LinkNode.java > * geode-core/src/test/java/com/examples/SuperClass.java > * geode-core/src/test/java/com/examples/TestObject.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7151) Remove some not used test classes
[ https://issues.apache.org/jira/browse/GEODE-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946351#comment-16946351 ] ASF subversion and git services commented on GEODE-7151: Commit a653e50134f6356002cf13faf1fae981dc21857e in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a653e50 ] GEODE-7151: Remove some unused classes (#3995) > Remove some not used test classes > - > > Key: GEODE-7151 > URL: https://issues.apache.org/jira/browse/GEODE-7151 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Trivial > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Following classes are not used and can be removed from the code: > * geode-core/src/test/java/com/examples/LinkNode.java > * geode-core/src/test/java/com/examples/SuperClass.java > * geode-core/src/test/java/com/examples/TestObject.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7237) CI failure: ConnectCommandAcceptanceTest.invalidHostname
[
https://issues.apache.org/jira/browse/GEODE-7237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946324#comment-16946324
]
ASF subversion and git services commented on GEODE-7237:
Commit 3686b4358eb088ab8e9a8a498bbcd14729a838b9 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3686b43 ]
GEODE-7237: Use invalid host name in ConnectCommandAcceptanceTest (#4128)
The test invalidHostname continues to fail intermittently. In the
failure, something fails to throw UnknownHostException. Having
spaces in the "invalid host name" should guarantee that it always
throws UnknownHostException now.
Also, remove the double negative from the assumeTrue by flipping it
to assumeFalse. Move the comment into the assumeFalse as a message.
> CI failure: ConnectCommandAcceptanceTest.invalidHostname
>
>
> Key: GEODE-7237
> URL: https://issues.apache.org/jira/browse/GEODE-7237
> Project: Geode
> Issue Type: Bug
> Components: ci, tests
>Reporter: Aaron Lindsey
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/1101]
> {code:java}
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
> > invalidHostname FAILED
> java.lang.AssertionError:
> Expecting:
> <"">
> to contain:
> <"can't be reached. Hostname or IP address could not be found.">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.invalidHostname(ConnectCommandAcceptanceTest.java:59)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6860) AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUniqueRanges runs for too long
[ https://issues.apache.org/jira/browse/GEODE-6860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-6860. -- Fix Version/s: 1.11.0 Resolution: Fixed > AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUniqueRanges > runs for too long > --- > > Key: GEODE-6860 > URL: https://issues.apache.org/jira/browse/GEODE-6860 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUniqueRanges > runs for too long. On a 12-core i9-8950HK 2.90GHz, the test takes 16.5 > minutes to run. Looking at the test, I see it has a for-loop of 1000 > iterations which seems excessive. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7228) v2 rest api configuration classes need more test coverage
[ https://issues.apache.org/jira/browse/GEODE-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7228. - Fix Version/s: 1.11.0 Resolution: Fixed > v2 rest api configuration classes need more test coverage > - > > Key: GEODE-7228 > URL: https://issues.apache.org/jira/browse/GEODE-7228 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.11.0 > > > Some of the settor methods on the AbstractConfiguration subclasses are never > called in tests that actually serialize the configuration into json. This > caused us to miss bug GEODE-7227. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7228) v2 rest api configuration classes need more test coverage
[ https://issues.apache.org/jira/browse/GEODE-7228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946205#comment-16946205 ] ASF subversion and git services commented on GEODE-7228: Commit 97f0a045e27fa4fc26ba3ee1d6e8214a0cbc in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=97f0a04 ] GEODE-7228: Test all config settors with serialization (#4126) > v2 rest api configuration classes need more test coverage > - > > Key: GEODE-7228 > URL: https://issues.apache.org/jira/browse/GEODE-7228 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Some of the settor methods on the AbstractConfiguration subclasses are never > called in tests that actually serialize the configuration into json. This > caused us to miss bug GEODE-7227. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7115) CI Failure: CreateRegionCommandPersistsConfigurationDUnitTest > createRegionWithColocation
[
https://issues.apache.org/jira/browse/GEODE-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946163#comment-16946163
]
Darrel Schneider commented on GEODE-7115:
-
It looks like what is flaky here is that after you create a region its mbean
may not be available right after the gfsh command returns.
This test does this:
{code:java}
gfsh.executeAndAssertThat("create region"
+ " --name=" + regionName
+ " --type=PARTITION_REDUNDANT").statusIsSuccess();
{code}
and then immediately does this:
{code:java}
gfsh.executeAndAssertThat("create region"
+ " --name=" + colocatedRegionName
+ " --colocated-with=" + regionName
+ " --type=PARTITION_REDUNDANT").statusIsSuccess();
{code}
The second one fails because it think the first region (named on
--colocated-with) does not exist.
The way it checks for existence is:
{code:java}
DistributedRegionMXBean colocatedRegionBean =
getManagementService().getDistributedRegionMXBean(prColocatedWith);
if (colocatedRegionBean == null) {
{code}
The code that is checking for the beens existence runs on the locator. So the
async part might be in this "federated" bean being pushed from the server that
created the region to the locator were this check is done.
The test could be changed to no longer fail by having some retry logic. But I
think in this case it is reasonable to expect the product to know that a
regions exists after you have successfully created one. I think we should fix
this by changing the product to do a better check. I think if we removed this
check from
org.apache.geode.management.internal.cli.commands.CreateRegionCommand.createRegion()
then eventually the check will be done by the core on the server when you
actually create the region in the internal function. So one option is to just
allow the core to do this check instead of trying to do it based on beans on
the locator. The locator could also look for the region in cluster config (if
it is enabled) which should not have a race. Or the locator could do some
retries waiting for the bean to show up.
> CI Failure: CreateRegionCommandPersistsConfigurationDUnitTest >
> createRegionWithColocation
> --
>
> Key: GEODE-7115
> URL: https://issues.apache.org/jira/browse/GEODE-7115
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1015
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandPersistsConfigurationDUnitTest
> > createRegionWithColocation FAILED
> org.junit.ComparisonFailure: [Specify a valid region path for
> colocated-with. Region /createRegionWithColocation not found.
> ] expected:<[OK]> but was:<[ERROR]>
> 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.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
> at
> org.apache.geode.management.internal.cli.commands.CreateRegionCommandPersistsConfigurationDUnitTest.createRegionWithColocation(CreateRegionCommandPersistsConfigurationDUnitTest.java:442)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7274) CI failure: org.apache.geode.management.internal.cli.commands.ChangeLogLevelCommandOverHttpDistributedTest > classMethod FAILED
[ https://issues.apache.org/jira/browse/GEODE-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7274. - Resolution: Duplicate > CI failure: > org.apache.geode.management.internal.cli.commands.ChangeLogLevelCommandOverHttpDistributedTest > > classMethod FAILED > --- > > Key: GEODE-7274 > URL: https://issues.apache.org/jira/browse/GEODE-7274 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.11.0 >Reporter: Anilkumar Gingade >Priority: Major > > java.lang.AssertionError: Suspicious strings were written to the log during > this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 1941 > [fatal 2019/10/04 16:53:01.296 GMT tid=153] Uncaught > exception in thread Thread[FederatingManager3,5,RMI Runtime] > org.apache.geode.cache.RegionDestroyedException: > org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_10.0.0.12041001';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE] > at > org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293) > at > org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157) > at > org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821) > at > org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128) > at > org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251) > at > org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:452) > at > org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216) > at > org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67) > at > org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564) > 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) > at org.junit.Assert.fail(Assert.java:88) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:386) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:185) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:69) > at > org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:140) > at > org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at >
[jira] [Commented] (GEODE-7264) Jackson-databind vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946076#comment-16946076 ] Joris Melchior commented on GEODE-7264: --- The linked issue fix resolves this issue as well. > Jackson-databind vulnerabilities > > > Key: GEODE-7264 > URL: https://issues.apache.org/jira/browse/GEODE-7264 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Gang Yan >Priority: Major > > In case it is by when the customer can expect a patch that addresses these > vulnerabilities? > [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814] > [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7276) CI failure: Benchmark PartitionedPutBenchmark analysis failed
Barrett Oglesby created GEODE-7276:
--
Summary: CI failure: Benchmark PartitionedPutBenchmark analysis
failed
Key: GEODE-7276
URL: https://issues.apache.org/jira/browse/GEODE-7276
Project: Geode
Issue Type: Bug
Components: benchmarks
Reporter: Barrett Oglesby
Benchmark test 615
(https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/615)
failed with:
{noformat}
BENCHMARK FAILED: org.apache.geode.benchmark.tests.PartitionedPutBenchmark
missing result file.
BENCHMARK FAILED: org.apache.geode.benchmark.tests.PartitionedPutBenchmark
missing result file.
{noformat}
The Analyzer is attempting to compare the test with the baseline and not
finding a
{noformat}
for (BenchmarkRunResult.ProbeResult probeResult : benchmarkResult.probeResults)
{
if (isNaN(probeResult.baseline) || isNaN(probeResult.test)) {
errorMessage.append("BENCHMARK FAILED: ").append(benchmarkResult.name)
.append(" missing result file.\n");
{noformat}
The output for the PartitionedPutBenchmark is:
{noformat}
org.apache.geode.benchmark.tests.PartitionedPutBenchmark
average ops/second Baseline:204975.67 Test: NaN
Difference:NaN%
ops/second standard error Baseline: 308.71 Test: NaN
Difference:NaN%
ops/second standard deviation Baseline: 5338.09 Test:-0.00
Difference: -100.0%
YS 99th percentile latency Baseline: 3808.00 Test: 3510.00
Difference: -7.8%
median latency Baseline:575487.00 Test:568319.00
Difference: -1.2%
90th percentile latency Baseline: 4476927.00 Test: 4378623.00
Difference: -2.2%
99th percentile latency Baseline: 9379839.00 Test: 9543679.00
Difference: +1.7%
99.9th percentile latency Baseline: 51118079.00 Test: 52002815.00
Difference: +1.7%
average latency Baseline: 1754859.17 Test: 1757899.99
Difference: +0.2%
latency standard deviation Baseline: 3494292.88 Test: 5794614.66
Difference: +65.8%
latency standard error Baseline: 445.63 Test: 2335.52
Difference: +424.1%
{noformat}
It would be nice if the BENCHMARK FAILED message printed the
probeResult.description, but I guess the two BENCHMARK FAILED messages
correspond to average ops/second and ops/second standard error since those are
the two NAN values.
There are several RuntimeException in both the baseline and branch client.log
files, but since both of the files contain those, it doesn't look related.
{noformat}
[RMI TCP Connection(1)-172.31.46.146] WARN org.reflections.Reflections - could
not create Dir using directory from url
file:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so. skipping.
java.lang.RuntimeException: cannot use dir
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so
[RMI TCP Connection(1)-172.31.46.146] WARN org.reflections.Reflections - could
not create Vfs.Dir from url. ignoring the exception and continuing
org.reflections.ReflectionsException: could not create Vfs.Dir from url, no
matching UrlType was found
[file:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/libatk-wrapper.so]
either use fromURL(final URL url, final List urlTypes) or use the
static setDefaultURLTypes(final List urlTypes) or
addDefaultURLTypes(UrlType urlType) with your specialized UrlType.
{noformat}
On the other hand, the branch client.log file contains this exception, but
unfortunately, the servers look to be configured with warn log level, so its
hard to tell why this exception occurred, and if its even relevant.
{noformat}
Finishing main test [ts=1570353668642, date=Sun Oct 06 09:21:08 UTC 2019]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
org.apache.geode.cache.client.ServerConnectivityException: Pool unexpected
socket timed out on client connection=Pooled Connection to
ip-172-31-42-223.us-west-2.compute.internal:46801: Connection[DESTROYED]
attempt=2). Server unreachable: could not connect after 2 attempts
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:771)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:159)
at
[jira] [Commented] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945998#comment-16945998 ] Barrett Oglesby commented on GEODE-7026: This failed again: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/383 > LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles > fails on Windows > - > > Key: GEODE-7026 > URL: https://issues.apache.org/jira/browse/GEODE-7026 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Donal Evans >Priority: Major > Labels: IntegrationTest, Windows, flaky > > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681] > org.awaitility.core.ConditionTimeoutException: Assertion condition defined > as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase > expected:<[online]> but was:<[not responding]> within 300 seconds. > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682] > > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683] > Caused by: > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684] > org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]> > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7264) Jackson-databind vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945970#comment-16945970 ] Joris Melchior commented on GEODE-7264: --- See security bulletin for details: [Debian security bulletin|[https://lists.debian.org/debian-lts-announce/2019/06/msg00019.html]] TLDR; for the exploit to work JDOM 1.x or JDOM 2.x or logback-core jar files have to be present in the class path. Unless Geode users have added these files themselves these jar files are not included in the Geode distribution. > Jackson-databind vulnerabilities > > > Key: GEODE-7264 > URL: https://issues.apache.org/jira/browse/GEODE-7264 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Gang Yan >Priority: Major > > In case it is by when the customer can expect a patch that addresses these > vulnerabilities? > [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814] > [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7264) Jackson-databind vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945970#comment-16945970 ] Joris Melchior edited comment on GEODE-7264 at 10/7/19 3:39 PM: See security bulletin for details: [Debian security bulletin|[https://lists.debian.org/debian-lts-announce/2019/06/msg00019.html]] TLDR; for the exploit to work JDOM 1.x or JDOM 2.x or logback-core jar files have to be present in the class path. Unless Geode users have added these files themselves these jar files are not part of the Geode distribution. was (Author: joris.melchior): See security bulletin for details: [Debian security bulletin|[https://lists.debian.org/debian-lts-announce/2019/06/msg00019.html]] TLDR; for the exploit to work JDOM 1.x or JDOM 2.x or logback-core jar files have to be present in the class path. Unless Geode users have added these files themselves these jar files are not included in the Geode distribution. > Jackson-databind vulnerabilities > > > Key: GEODE-7264 > URL: https://issues.apache.org/jira/browse/GEODE-7264 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Gang Yan >Priority: Major > > In case it is by when the customer can expect a patch that addresses these > vulnerabilities? > [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814] > [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6988) Implement JavaBeanAccessorMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-6988. --- Fix Version/s: 1.11.0 Resolution: Fixed > Implement JavaBeanAccessorMethodAuthorizer > -- > > Key: GEODE-6988 > URL: https://issues.apache.org/jira/browse/GEODE-6988 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Donal Evans >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Implement the [JavaBeanAccessorMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-JavaBeanAccessorMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6988) Implement JavaBeanAccessorMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945909#comment-16945909 ] ASF subversion and git services commented on GEODE-6988: Commit bbe3259f6ebecfaf9fd7fc8cc0129c33f3c3fbbf in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbe3259 ] GEODE-6988: Implement JavaBeanAccessorMethodAuthorizer (#4116) - Made the class final, immutable and thread safe. - Added comprehensive javadocs to the class and its methods. - Added several unit tests for the class and all public methods. > Implement JavaBeanAccessorMethodAuthorizer > -- > > Key: GEODE-6988 > URL: https://issues.apache.org/jira/browse/GEODE-6988 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Donal Evans >Priority: Major > Labels: GeodeCommons > Time Spent: 2h 40m > Remaining Estimate: 0h > > Implement the [JavaBeanAccessorMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-JavaBeanAccessorMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6986) Implement UnrestrictedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-6986. --- Fix Version/s: 1.11.0 Resolution: Fixed > Implement UnrestrictedMethodAuthorizer > -- > > Key: GEODE-6986 > URL: https://issues.apache.org/jira/browse/GEODE-6986 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implement the [UnrestrictedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-UnrestrictedMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6986) Implement UnrestrictedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945904#comment-16945904 ] ASF subversion and git services commented on GEODE-6986: Commit 33ac0052ff2d9778ee25e0ab568732998baf343b in geode's branch refs/heads/develop from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=33ac005 ] GEODE-6986: Implement UnrestrictedMethodAuthorizer (#4105) * GEODE-6986: Implement UnrestrictedMethodAuthorizer - Made the class final, immutable and thread safe. - Added comprehensive javadocs to the class and its methods. - Added several unit tests for the class and all public methods. - Improved javadocs for 'RestrictedMethodAuthorizer' and 'MethodInvocationAuthorizer'. - Fixed 'RestrictedMethodAuthorizer.isAllowedGeodeMethod()' to allow the execution of 'toString' and 'equals' on Geode objects. - Removed 'getNanos' from the accepted methods for 'java.lang.Date' in 'RestrictedMethodAuthorizer' (the method belong to 'java.sql.Timestamp' instead). > Implement UnrestrictedMethodAuthorizer > -- > > Key: GEODE-6986 > URL: https://issues.apache.org/jira/browse/GEODE-6986 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implement the [UnrestrictedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-UnrestrictedMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6986) Implement UnrestrictedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945903#comment-16945903 ] ASF subversion and git services commented on GEODE-6986: Commit 33ac0052ff2d9778ee25e0ab568732998baf343b in geode's branch refs/heads/develop from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=33ac005 ] GEODE-6986: Implement UnrestrictedMethodAuthorizer (#4105) * GEODE-6986: Implement UnrestrictedMethodAuthorizer - Made the class final, immutable and thread safe. - Added comprehensive javadocs to the class and its methods. - Added several unit tests for the class and all public methods. - Improved javadocs for 'RestrictedMethodAuthorizer' and 'MethodInvocationAuthorizer'. - Fixed 'RestrictedMethodAuthorizer.isAllowedGeodeMethod()' to allow the execution of 'toString' and 'equals' on Geode objects. - Removed 'getNanos' from the accepted methods for 'java.lang.Date' in 'RestrictedMethodAuthorizer' (the method belong to 'java.sql.Timestamp' instead). > Implement UnrestrictedMethodAuthorizer > -- > > Key: GEODE-6986 > URL: https://issues.apache.org/jira/browse/GEODE-6986 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 20m > Remaining Estimate: 0h > > Implement the [UnrestrictedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-UnrestrictedMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
