[jira] [Updated] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9635: -- Labels: pull-request-available (was: ) > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
[ https://issues.apache.org/jira/browse/GEODE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9629: -- Labels: needsTriage pull-request-available (was: needsTriage) > GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API > - > > Key: GEODE-9629 > URL: https://issues.apache.org/jira/browse/GEODE-9629 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: needsTriage, pull-request-available > > GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the > public API. > The problem with this is that Geode should not allow for the simple > modification of settings for a GatewaySender. Without proper process / > management around the changing of the properties it would be too simple to > introduce side-effects by changing settings on the GatewaySender. > We (Geode) should NOT allow for the direct manipulation of configuration of > ANY component without it having gone through a controlled process, to ensure > that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421855#comment-17421855
]
Geode Integration commented on GEODE-9528:
--
Seen on support/1.13 in [integration-test-openjdk8
#52|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/integration-test-openjdk8/builds/52]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0601/test-results/integrationTest/1632877206/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0601/test-artifacts/1632877206/integrationtestfiles-openjdk8-1.13.5-build.0601.tgz].
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421857#comment-17421857
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#219|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/219].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Updated] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8200:
--
Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was:
GeodeOperationAPI blocks-1.15.0)
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7";,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances";
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9655. - Fix Version/s: 1.14.1 1.13.5 1.12.5 Resolution: Fixed bumped Shiro from 1.7.1 to 1.8.0 on support branches. develop was already at 1.8.0 > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > Fix For: 1.12.5, 1.13.5, 1.14.1 > > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421839#comment-17421839 ] ASF subversion and git services commented on GEODE-9655: Commit e4aee56d4edc9bc86f5f99c42fc61c4d502cc0b2 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4aee56 ] GEODE-9655: Bump shiro-core from 1.7.1 to 1.8.0 > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421838#comment-17421838 ] ASF subversion and git services commented on GEODE-9655: Commit 803f46d8dbc875954a6cde88a2cbdca891ebee39 in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=803f46d ] GEODE-9655: Bump shiro-core from 1.7.1 to 1.8.0 > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421831#comment-17421831 ] ASF subversion and git services commented on GEODE-9655: Commit f8371a9506d6800995d1cf015c19867e9beb1ad8 in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8371a9 ] GEODE-9655: Bump shiro-core from 1.7.1 to 1.8.0 > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9655: Affects Version/s: (was: 1.15.0) > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9655) bump shiro to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9655: - Labels: needsTriage (was: ) > bump shiro to recommended version > - > > Key: GEODE-9655 > URL: https://issues.apache.org/jira/browse/GEODE-9655 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9655) bump shiro to recommended version
Owen Nichols created GEODE-9655: --- Summary: bump shiro to recommended version Key: GEODE-9655 URL: https://issues.apache.org/jira/browse/GEODE-9655 Project: Geode Issue Type: Bug Components: pulse Affects Versions: 1.14.0, 1.13.4, 1.12.4, 1.15.0 Reporter: Owen Nichols 1.8.0 was just released and we should update to it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9654) Add system property for configuring redis timeouts
[ https://issues.apache.org/jira/browse/GEODE-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9654: - Assignee: Hale Bales > Add system property for configuring redis timeouts > -- > > Key: GEODE-9654 > URL: https://issues.apache.org/jira/browse/GEODE-9654 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > > We have a some hard coded timeouts in our redis module that may or may not > work in our customer environments. We should probably make some these things > configurable with system properties so support could help customers get pass > issues if these timeouts don't work. > In NettyRedisServer: > - CONNECT_TIMEOUT_MILLIS > - new WriteTimeoutHandler(10) > PassiveExpirationManager.INTERVAL > We shall sweep through the code and find other hardcoded constants and see if > we want there to be a chance for support to configure them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9654) Add system property for configuring redis timeouts
Hale Bales created GEODE-9654: - Summary: Add system property for configuring redis timeouts Key: GEODE-9654 URL: https://issues.apache.org/jira/browse/GEODE-9654 Project: Geode Issue Type: Improvement Components: redis Reporter: Hale Bales We have a some hard coded timeouts in our redis module that may or may not work in our customer environments. We should probably make some these things configurable with system properties so support could help customers get pass issues if these timeouts don't work. In NettyRedisServer: - CONNECT_TIMEOUT_MILLIS - new WriteTimeoutHandler(10) PassiveExpirationManager.INTERVAL We shall sweep through the code and find other hardcoded constants and see if we want there to be a chance for support to configure them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9651) LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing failed with AuthenticationRequiredException
[
https://issues.apache.org/jira/browse/GEODE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami updated GEODE-9651:
--
Summary: LuceneClientSecurityPostProcessingDUnitTest >
verifyPdxPostProcessing failed with AuthenticationRequiredException (was:
LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED)
> LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing failed
> with AuthenticationRequiredException
> -
>
> Key: GEODE-9651
> URL: https://issues.apache.org/jira/browse/GEODE-9651
> Project: Geode
> Issue Type: Bug
> Components: lucene, security
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> This failure may be related to GEODE-9643.
> {noformat}
> org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest >
> verifyPdxPostProcessing 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 'dunit_suspect-vm0.log' at line 455[fatal
> 2021/09/28 00:23:59.861 UTC
> tid=125] Uncaught exception in thread Thread[ServerConnection on port 44721
> Thread 3,5,RMI Runtime]
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:908)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:863)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1050)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1316)
> 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.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:829)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> a
[jira] [Commented] (GEODE-9653) ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest > serverVersioningTest[version=1.9.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421820#comment-17421820
]
Geode Integration commented on GEODE-9653:
--
Seen in [upgrade-test-openjdk11
#213|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/213]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-results/upgradeTest/1632793559/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-artifacts/1632793559/upgradetestfiles-openjdk11-1.15.0-build.0516.tgz].
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest >
> serverVersioningTest[version=1.9.1] FAILED
> ---
>
> Key: GEODE-9653
> URL: https://issues.apache.org/jira/browse/GEODE-9653
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.rules.tests.ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
> > serverVersioningTest[version=1.9.1] 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 'dunit_suspect-vm0.log' at line 350[fatal
> 2021/09/28 00:08:38.644 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 357[fatal
> 2021/09/28 00:08:38.657 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 364[fatal
> 2021/09/28 00:08:38.657 UTC tid=48] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(Par
[jira] [Created] (GEODE-9653) ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest > serverVersioningTest[version=1.9.1] FAILED
Kamilla Aslami created GEODE-9653:
-
Summary: ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest >
serverVersioningTest[version=1.9.1] FAILED
Key: GEODE-9653
URL: https://issues.apache.org/jira/browse/GEODE-9653
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Kamilla Aslami
{noformat}
org.apache.geode.test.dunit.rules.tests.ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
> serverVersioningTest[version=1.9.1] 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 'dunit_suspect-vm0.log' at line 350[fatal
2021/09/28 00:08:38.644 UTC tid=47] Exception in
processing request from 10.0.0.30
java.lang.Exception: Improperly configured client detected - use
addPoolLocator to configure its locators instead of addPoolServer.
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
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:829)
---
Found suspect string in 'dunit_suspect-vm0.log' at line 357[fatal
2021/09/28 00:08:38.657 UTC tid=47] Exception in
processing request from 10.0.0.30
java.lang.Exception: Improperly configured client detected - use
addPoolLocator to configure its locators instead of addPoolServer.
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
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:829)
---
Found suspect string in 'dunit_suspect-vm0.log' at line 364[fatal
2021/09/28 00:08:38.657 UTC tid=48] Exception in
processing request from 10.0.0.30
java.lang.Exception: Improperly configured client detected - use
addPoolLocator to configure its locators instead of addPoolServer.
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
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:829)
at org.junit.Assert.fail(Assert.java:89)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunne
[jira] [Updated] (GEODE-9653) ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest > serverVersioningTest[version=1.9.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9653:
-
Labels: needsTriage (was: )
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest >
> serverVersioningTest[version=1.9.1] FAILED
> ---
>
> Key: GEODE-9653
> URL: https://issues.apache.org/jira/browse/GEODE-9653
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.rules.tests.ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
> > serverVersioningTest[version=1.9.1] 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 'dunit_suspect-vm0.log' at line 350[fatal
> 2021/09/28 00:08:38.644 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 357[fatal
> 2021/09/28 00:08:38.657 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 364[fatal
> 2021/09/28 00:08:38.657 UTC tid=48] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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:829)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.r
[jira] [Commented] (GEODE-9651) LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED
[
https://issues.apache.org/jira/browse/GEODE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421814#comment-17421814
]
Geode Integration commented on GEODE-9651:
--
Seen in [distributed-test-openjdk11
#218|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/218]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-results/distributedTest/1632794919/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-artifacts/1632794919/distributedtestfiles-openjdk11-1.15.0-build.0516.tgz].
> LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED
>
>
> Key: GEODE-9651
> URL: https://issues.apache.org/jira/browse/GEODE-9651
> Project: Geode
> Issue Type: Bug
> Components: lucene, security
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> This failure may be related to GEODE-9643.
> {noformat}
> org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest >
> verifyPdxPostProcessing 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 'dunit_suspect-vm0.log' at line 455[fatal
> 2021/09/28 00:23:59.861 UTC
> tid=125] Uncaught exception in thread Thread[ServerConnection on port 44721
> Thread 3,5,RMI Runtime]
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:908)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:863)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1050)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1316)
> 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.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:829)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>
[jira] [Created] (GEODE-9652) Geode for Redis Rename - doc followup
Dave Barnes created GEODE-9652: -- Summary: Geode for Redis Rename - doc followup Key: GEODE-9652 URL: https://issues.apache.org/jira/browse/GEODE-9652 Project: Geode Issue Type: Sub-task Components: docs Affects Versions: 1.15.0 Reporter: Dave Barnes After GEODE-9567 has been completed, follow up in the user guide sources to tidy up doc loose ends. Task list (add to this if needed): - Verify that the "Experimental" modifier has been removed from all occurrences of Geode for Redis, as per GEODE-9566. - Move the Geode for Redis section entry in the left-hand navigation pane from "Developing..." to "Tools and Modules". Suggested location: following gfsh, before Gemcached. Check for affected references, for example in the Developing intro. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9651) LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED
[
https://issues.apache.org/jira/browse/GEODE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9651:
-
Labels: needsTriage (was: )
> LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED
>
>
> Key: GEODE-9651
> URL: https://issues.apache.org/jira/browse/GEODE-9651
> Project: Geode
> Issue Type: Bug
> Components: lucene, security
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> This failure may be related to GEODE-9643.
> {noformat}
> org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest >
> verifyPdxPostProcessing 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 'dunit_suspect-vm0.log' at line 455[fatal
> 2021/09/28 00:23:59.861 UTC
> tid=125] Uncaught exception in thread Thread[ServerConnection on port 44721
> Thread 3,5,RMI Runtime]
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:908)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:863)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1050)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1316)
> 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.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:829)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.Par
[jira] [Created] (GEODE-9651) LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing FAILED
Kamilla Aslami created GEODE-9651:
-
Summary: LuceneClientSecurityPostProcessingDUnitTest >
verifyPdxPostProcessing FAILED
Key: GEODE-9651
URL: https://issues.apache.org/jira/browse/GEODE-9651
Project: Geode
Issue Type: Bug
Components: lucene, security
Reporter: Kamilla Aslami
This failure may be related to GEODE-9643.
{noformat}
org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest >
verifyPdxPostProcessing 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 'dunit_suspect-vm0.log' at line 455[fatal
2021/09/28 00:23:59.861 UTC tid=125]
Uncaught exception in thread Thread[ServerConnection on port 44721 Thread
3,5,RMI Runtime]
org.apache.geode.security.AuthenticationRequiredException: Failed to find
the authenticated user.
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:908)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:863)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1050)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1316)
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.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.base/java.lang.Thread.run(Thread.java:829)
at org.junit.Assert.fail(Assert.java:89)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClas
[jira] [Commented] (GEODE-9448) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException
[
https://issues.apache.org/jira/browse/GEODE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421811#comment-17421811
]
Geode Integration commented on GEODE-9448:
--
Seen in [distributed-test-openjdk11
#221|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/221]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-results/distributedTest/1632851453/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-artifacts/1632851453/distributedtestfiles-openjdk11-1.15.0-build.0519.tgz].
> CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with
> ConditionTimeoutException caused by TimeoutException
>
>
> Key: GEODE-9448
> URL: https://issues.apache.org/jira/browse/GEODE-9448
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kamilla Aslami
>Priority: Major
>
> This failure is similar to GEODE-8191 but the stack trace looks a bit
> different:
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but
> was:<[375]0> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108)
> Caused by:
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102)
> ... 5 more{noformat}
> I noticed that in the last failure reported on GEODE-8191 ([run
> #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/26]),
> the version of Awaitility was 4.0.3. In this failure, the version is 4.1.0,
> so this might be the reason why the stack traces are different.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8200) Rebalance operations stuck in "IN_PROGRESS" state forever
[
https://issues.apache.org/jira/browse/GEODE-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade reassigned GEODE-8200:
Assignee: Anilkumar Gingade (was: Jianxia Chen)
> Rebalance operations stuck in "IN_PROGRESS" state forever
> -
>
> Key: GEODE-8200
> URL: https://issues.apache.org/jira/browse/GEODE-8200
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0
> Attachments: GEODE-8200-exportedLogs.zip
>
>
> We use the management REST API to call rebalance immediately before stopping
> a server to limit the possibility of data loss. In a cluster with 3 locators,
> 3 servers, and no regions, we noticed that sometimes the rebalance operation
> never ends if one of the locators is restarting concurrently with the
> rebalance operation.
> More specifically, the scenario where we see this issue crop up is during an
> automated "rolling restart" operation in a Kubernetes environment which
> proceeds as follows:
> * At most one locator and one server are restarting at any point in time
> * Each locator/server waits until the previous locator/server is fully online
> before restarting
> * Immediately before stopping a server, a rebalance operation is performed
> and the server is not stopped until the rebalance operation is completed
> The impact of this issue is that the "rolling restart" operation will never
> complete, because it cannot proceed with stopping a server until the
> rebalance operation is completed. A human is then required to intervene and
> manually trigger a rebalance and stop the server. This type of "rolling
> restart" operation is triggered fairly often in Kubernetes — any time part of
> the configuration of the locators or servers changes.
> The following JSON is a sample response from the management REST API that
> shows the rebalance operation stuck in "IN_PROGRESS".
> {code}
> {
> "statusCode": "IN_PROGRESS",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/a47f23c8-02b3-443c-a367-636fd6921ea7";,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances";
> },
> "operationStart": "2020-05-27T22:38:30.619Z",
> "operationId": "a47f23c8-02b3-443c-a367-636fd6921ea7",
> "operation": {
> "simulate": false
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421801#comment-17421801
]
Geode Integration commented on GEODE-8634:
--
Seen on support/1.13 in [distributed-test-openjdk8
#54|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/54]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-results/distributedTest/1632864335/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-artifacts/1632864335/distributedtestfiles-openjdk8-1.13.5-build.0600.tgz].
> CI failure: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> 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.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCau
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421795#comment-17421795
]
Geode Integration commented on GEODE-7710:
--
Seen on support/1.13 in [distributed-test-openjdk11
#54|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/54]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-results/distributedTest/1632863873/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-artifacts/1632863873/distributedtestfiles-openjdk11-1.13.5-build.0600.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne resolved GEODE-9546. -- Fix Version/s: 1.15.0 Resolution: Fixed > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-username > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used** > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > **When the AUTH command has a single argument (e.g. AUTH xx) the single > argument is interpreted as a password/token and the default Redis user is > used for authentication. When the AUTH command has two arguments (e.g. AUTH > xx yy) the first argument is interpreted as a username and is used > instead of the default Redis user. The second argument is interpreted as a > password. > +Acceptance Criteria+ > > When a SecurityManager is configured, Redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform Redis operations. Until we support ACLS, use of > the AUTH command with more than two arguments is invalid syntax. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne reassigned GEODE-9547: Assignee: Jens Deppe > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:WRITE:REDIS_DATA ?? In the future we may provide more fine grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne reassigned GEODE-9546: Assignee: Jens Deppe > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-username > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used** > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > **When the AUTH command has a single argument (e.g. AUTH xx) the single > argument is interpreted as a password/token and the default Redis user is > used for authentication. When the AUTH command has two arguments (e.g. AUTH > xx yy) the first argument is interpreted as a username and is used > instead of the default Redis user. The second argument is interpreted as a > password. > +Acceptance Criteria+ > > When a SecurityManager is configured, Redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform Redis operations. Until we support ACLS, use of > the AUTH command with more than two arguments is invalid syntax. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9649) enforce use of version constraints in build and pom
[ https://issues.apache.org/jira/browse/GEODE-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9649: -- Labels: pull-request-available (was: ) > enforce use of version constraints in build and pom > --- > > Key: GEODE-9649 > URL: https://issues.apache.org/jira/browse/GEODE-9649 > Project: Geode > Issue Type: Improvement > Components: build >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > Create a spotless rule that ensures all dependencies are fetched from the > constraints BOM where possible. Some exceptions are tomcat, for which we have > several different versions, all in their own sub-modules -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9650) Radish LOLWUT command
Ray Ingles created GEODE-9650: - Summary: Radish LOLWUT command Key: GEODE-9650 URL: https://issues.apache.org/jira/browse/GEODE-9650 Project: Geode Issue Type: New Feature Components: redis Affects Versions: 1.15.0 Reporter: Ray Ingles Implement the LOLWUT command, which allows command-line users to quickly check the software version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9649) enforce use of version constraints in build and pom
Robert Houghton created GEODE-9649: -- Summary: enforce use of version constraints in build and pom Key: GEODE-9649 URL: https://issues.apache.org/jira/browse/GEODE-9649 Project: Geode Issue Type: Improvement Components: build Affects Versions: 1.15.0 Reporter: Robert Houghton Create a spotless rule that ensures all dependencies are fetched from the constraints BOM where possible. Some exceptions are tomcat, for which we have several different versions, all in their own sub-modules -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421790#comment-17421790
]
Kamilla Aslami commented on GEODE-9528:
---
This issue was seen on support/1.13. [~boglesby] should/can we back-port this
fix to other versions of Geode?
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421788#comment-17421788
]
Geode Integration commented on GEODE-9528:
--
Seen on support/1.13 in [integration-test-openjdk8
#50|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/integration-test-openjdk8/builds/50]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-results/integrationTest/1632857544/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0600/test-artifacts/1632857544/integrationtestfiles-openjdk8-1.13.5-build.0600.tgz].
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9495) remove thread sleep from PubSubNativeRedisAcceptanceTest class cleanup
[ https://issues.apache.org/jira/browse/GEODE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421787#comment-17421787 ] ASF subversion and git services commented on GEODE-9495: Commit 2744ab8a902b665e655c02871c43db45562d800e in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2744ab8 ] GEODE-9495: limit thread sleep in pub sub native redis acceptance test (#6899) Looks up the actual TIME_WAIT timeout value on the operating systems generally used for development and in the CI pipeline. Updated to read the value in a different way on Linux. Co-authored-by: Ray Ingles > remove thread sleep from PubSubNativeRedisAcceptanceTest class cleanup > -- > > Key: GEODE-9495 > URL: https://issues.apache.org/jira/browse/GEODE-9495 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GEODE-9338 includes the addition of a Thread.sleep(24) in the class > cleanup. This wait is necessary to allow the sockets used in this class to > exit the TIME_WAIT state. Out of Mac, Linux, and Windows, Windows has the > longest default TIME_WAIT, which is 240 seconds. So currently at the end of > the PubSubNativeRedisAcceptanceTest tests, we wait for 240 seconds. > Another solution was proposed that involved parsing netstat outputs to find > out when enough sockets have been freed, but the complexity didn't buy us > much there. > A potential other solution would be to reduce the TIME_WAIT period when > running the tests in CI. > If we don't wait for the TIME_WAIT period to be up then other tests being run > after it will get bind exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9645:
--
Labels: needsTriage pull-request-available (was: needsTriage)
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> 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){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5940) ServerLauncherRemoteIntegrationTest times out waiting for server to start
[
https://issues.apache.org/jira/browse/GEODE-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421776#comment-17421776
]
Geode Integration commented on GEODE-5940:
--
Seen in [windows-core-integration-test-openjdk11
#214|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/214]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0520/test-results/integrationTest/1632861071/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0520/test-artifacts/1632861071/windows-coreintegrationtestfiles-openjdk11-1.15.0-build.0520.tgz].
> ServerLauncherRemoteIntegrationTest times out waiting for server to start
> -
>
> Key: GEODE-5940
> URL: https://issues.apache.org/jira/browse/GEODE-5940
> Project: Geode
> Issue Type: Test
>Reporter: Dale Emery
>Assignee: Kirk Lund
>Priority: Major
> Labels: swat
> Fix For: 1.11.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.50/test-results/integrationTest/1540492907/classes/org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.html#startOverwritesStalePidFile
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 300 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:890)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:200)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:178)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:128)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:124)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile(ServerLauncherRemoteIntegrationTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at or
[jira] [Commented] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421773#comment-17421773
]
ASF GitHub Bot commented on GEODE-6042:
---
alb3rtobr merged pull request #13:
URL: https://github.com/apache/geode-site/pull/13
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9642) Adding GW sender to allready initialized partitioned region is hanging in large cluster
[ https://issues.apache.org/jira/browse/GEODE-9642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421656#comment-17421656 ] Jens Deppe commented on GEODE-9642: --- Do you have any stack traces of the hanging process? > Adding GW sender to allready initialized partitioned region is hanging in > large cluster > --- > > Key: GEODE-9642 > URL: https://issues.apache.org/jira/browse/GEODE-9642 > Project: Geode > Issue Type: Bug > Components: regions, wan >Affects Versions: 1.13.0, 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > We have observed, that adding parallel GW sender to existing (allready > initialized) partitioned regions is hanging. > In case command alter-region is executed (attaching GW sender to initialized > region), it is hanging in cluster with more then 20 servers. > Execution of command in cluster with 16 or less servers was successful, but > if cluster is expanded to 20 or more, command is hanging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9647) MultiUserAuth: DataSerializer.Register throws when attempting to register a new DataSerializer.
[
https://issues.apache.org/jira/browse/GEODE-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-9647:
--
Assignee: Mark Hanson
> MultiUserAuth: DataSerializer.Register throws when attempting to register a
> new DataSerializer.
> ---
>
> Key: GEODE-9647
> URL: https://issues.apache.org/jira/browse/GEODE-9647
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> When multiuserSecureModeEnabled is set, a user may attempt to register a
> DataSerializer, but will get the following error. The reason is that the
> PoolImpl needs credentials to authenticate against, which it does not have.
>
> {noformat}
> [warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
> instantiator on pool:java.lang.UnsupportedOperationException: Use Pool APIs
> for doing operations when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:34)
>
> at
> org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterDataSerializers(PoolManagerImpl.java:264)
>
> at
> org.apache.geode.internal.InternalDataSerializer.sendRegistrationMessageToServers(InternalDataSerializer.java:1197)
>
> at
> org.apache.geode.internal.InternalDataSerializer._register(InternalDataSerializer.java:1093)
>
> at
> org.apache.geode.internal.InternalDataSerializer.register(InternalDataSerializer.java:966)
> at org.apache.geode.DataSerializer.register(DataSerializer.java:2900)
> at
> org.apache.geode.management.internal.security.MultiUserAuthenticationDUnitTest.multiAuthenticatedView(MultiUserAuthenticationDUnitTest.java:152)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
>
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
>
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
>
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
>
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
>
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-9645:
--
Assignee: Mark Hanson
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> 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){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421610#comment-17421610
]
ASF subversion and git services commented on GEODE-9486:
Commit 5b067cae5257e871055acebc94b944d36afb59e9 in geode's branch
refs/heads/support/1.13 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5b067ca ]
GEODE-9486: Fix validate-serializable-objects (#6823)
Rename DistributedSystemService to SanctionedSerializablesService and
remove unused init(DistributedSystem).
Move SanctionedSerializablesService to geode-serialization.
Implement SanctionedSerializablesService in both geode-core and
geode-management to remove special case for each in
InternalDataSerializer.
Fix sanctioned serializables support in geode-management and
geode-apis-compatible-with-redis.
Add sanctioned serializables support to geode-serialization and
geode-pulse.
Add sanctioned serializables support to geode-junit and geode-dunit
to simplify writing tests for validate-serializable-objects and prevent
having to list out DUnit Rules and other test framework classes when
validate-serializable-objects is enabled.
Use ExecutorServiceRule and reformat json strings in
RestRegionAPIIntegrationTest.
Reorganize QueryCommandDUnitTestBase.
Use InvalidClassException instead of Exception in
ObjectInputStreamFilterWrapper fatal log message.
Improve assertion messages in ResourceUtils.
Move loadSanctionedSerializablesServices and loadClassNames to
new SanctionedSerializables in geode-serialization.
Exclude Pulse GemFireAuthentication from sanctioned serializables.
Add SerializationTest Category to all AnalyzeSerializables integration
tests.
Tidy up SANCTIONED_SERIALIZABLES_DEPENDENCIES_PATTERN.
Convert to AssertJ and use BeforeClass in
InternalDataSerializerSerializationAcceptlistTest.
Note: If Git or GitHub is showing invalid file renames in the diffs, you
may need to pull the branch locally and configure diff.renameLimit to
something lower than the default value of 50.
(cherry picked from commit acbd0ff3c37a5e1fe3018d3f7288df385159ac4c)
(cherry picked from commit ba81c3670d85dbb4451030e2c4acb11ca8aef9da)
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sa
[jira] [Commented] (GEODE-9486) Serialized classes in geode-serializable fail to deserialize when validate-serializable-objects is enabled
[
https://issues.apache.org/jira/browse/GEODE-9486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421611#comment-17421611
]
ASF subversion and git services commented on GEODE-9486:
Commit c685f06f64b8c7d9d160201db1b99597e53ce9d9 in geode's branch
refs/heads/support/1.13 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c685f06 ]
GEODE-9486: Improve AnalyzeSerializables integration tests (#6878)
Allow geode modules to have an AnalyzeSerializables integration
test without implementing SanctionedSerializablesService.
Improve debugging information for AnalyzeSerializables integration
tests:
- Provide new failure message when no SanctionedSerializablesService
exists.
- Create ANALYZE_SERIALIZABLES.md to provide detailed instructions for
failures involving AnalyzeSerializables integration tests.
- Reference ANALYZE_SERIALIZABLES.md in failure messages.
Remove geode-serialization and geode-common jars from geode-pulse
.war file:
- Change getModuleClass() to return Optional.
- Delete PulseSanctionedSerializablesService and its resources.
- Change geode-pulse dependency on geode-serialization to be for
integrationTest only.
(cherry picked from commit 7bd1d73dcd02712a10e5c3f2ac5ac0522923bf9e)
(cherry picked from commit 14582d05ed0032f5315313e3d29c1773b7bf0f53)
> Serialized classes in geode-serializable fail to deserialize when
> validate-serializable-objects is enabled
> --
>
> Key: GEODE-9486
> URL: https://issues.apache.org/jira/browse/GEODE-9486
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Serialized classes in geode-serializable fail to deserialize when
> {{validate-serializable-objects}} is enabled. This bug was caught by
> {{SessionsAndCrashesDUnitTest}} in geode-apis-compatible-with-redis
> (GEODE-9485):
> {noformat}
> [fatal 2021/08/04 13:50:57.548 UTC tid=114]
> Serialization filter is rejecting class
> org.apache.geode.internal.serialization.DSFIDNotFoundException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:234)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at
> java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1336)
> at
> java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)
> at
> java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1862)
> at
> java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2169)
> at
> java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1679)
> {noformat}
> Any module with a class that may be serialized must implement
> {{DistributedSystemService}} to provide the list of sanctioned serializables
> as defined in {{sanctionedDataSerializables.txt}} and a concrete test
> subclassing {{AnalyzeSerializablesJUnitTestBase}}.
> {{org.apache.geode.internal.serialization.DSFIDNotFoundException}} is in
> geode-serialization which cannot depend on geode-core which owns
> {{DistributedSystemService}}. Even if we remove the unused {{void
> init(InternalDistributedSystem internalDistributedSystem)}} and move it to
> geode-serialization, {{SerializationDistributedSystemService}} would need to
> implement {{getSerializationAcceptlist()}} as:
> {noformat}
> @Override
> public Collection getSerializationAcceptlist() throws IOException {
> URL sanctionedSerializables =
> ClassPathLoader.getLatest().getResource(getClass(),
> "sanctioned-geode-gfsh-serializables.txt");
> return InternalDataSerializer.loadClassNames(sanctionedSerializables);
> }
> {noformat}
> ... which uses {{ClassPathLoader}} and {{InternalDataSerializer}} which live
> in geode-core.
> This requires moving the classes {{ClassPathLoader}} and
> {{InternalDataSerializer}} that need to be used within
> {{getSerializationAcceptlist()}}.
> {{ClassPathLoader}} depends on geode deployment:
> {noformat}
> import org.apache.geode.internal.deployment.DeploymentServiceFactory;
> import org.apache.geode.internal.deployment.JarDeploymentService;
> {noformat}
> {{InternalDataSerializer}} gets even more complicated with many dependencies.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9648) Remove usage of std::unary_function and std::binary_function
[
https://issues.apache.org/jira/browse/GEODE-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-9648:
-
Description: Remove usage of {{std::unary_function}} and
{{std::binary_function}} since they were deprecated in C++ 11 and removed in
C++ 17. (was: Remove usage of {{std::unary_function}} since it was deprecated
in C++ 11 and removed in C++ 17.)
Summary: Remove usage of std::unary_function and std::binary_function
(was: Remove usage of std::unary_function)
> Remove usage of std::unary_function and std::binary_function
>
>
> Key: GEODE-9648
> URL: https://issues.apache.org/jira/browse/GEODE-9648
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Jacob Barrett
>Priority: Major
>
> Remove usage of {{std::unary_function}} and {{std::binary_function}} since
> they were deprecated in C++ 11 and removed in C++ 17.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9648) Remove usage of std::unary_function
Jacob Barrett created GEODE-9648:
Summary: Remove usage of std::unary_function
Key: GEODE-9648
URL: https://issues.apache.org/jira/browse/GEODE-9648
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Jacob Barrett
Remove usage of {{std::unary_function}} since it was deprecated in C++ 11 and
removed in C++ 17.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421572#comment-17421572
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#216|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/216].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Commented] (GEODE-9641) Benchmark instability in P2pPartitionedPutBytesBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421573#comment-17421573
]
Geode Integration commented on GEODE-9641:
--
Seen in [benchmark-base
#217|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/217].
> Benchmark instability in P2pPartitionedPutBytesBenchmark
>
>
> Key: GEODE-9641
> URL: https://issues.apache.org/jira/browse/GEODE-9641
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> P2pPartitionedPutBytesBenchmark started failing in CI after the fix for
> GEODE-9204 was merged.
> {code:java}
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark
> average ops/second Baseline:179582.83 Test:170268.31
> Difference: -5.2%
>ops/second standard error Baseline: 849.15 Test: 649.44
> Difference: -23.5%
>ops/second standard deviation Baseline: 25346.86 Test: 19374.76
> Difference: -23.6%
> YS 99th percentile latency Baseline: 5010.00 Test: 5110.00
> Difference: +2.0%
> median latency Baseline: 2416639.00 Test: 2412543.00
> Difference: -0.2%
> 90th percentile latency Baseline: 4698111.00 Test: 4567039.00
> Difference: -2.8%
> 99th percentile latency Baseline: 38141951.00 Test: 81723391.00
> Difference: +114.3%
>99.9th percentile latency Baseline: 196214783.00 Test: 205389823.00
> Difference: +4.7%
> average latency Baseline: 4033453.68 Test: 4258029.39
> Difference: +5.6%
> latency standard deviation Baseline: 14549153.77 Test: 15673393.37
> Difference: +7.7%
> latency standard error Baseline: 1149.00 Test: 1271.79
> Difference: +10.7%
> average ops/second Baseline:533863.27 Test:505986.13
> Difference: -5.2%
> BENCHMARK FAILED:
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark average
> latency is 5% worse than baseline.{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421571#comment-17421571
]
Geode Integration commented on GEODE-7710:
--
Seen in [distributed-test-openjdk11
#219|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/219]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-results/distributedTest/1632805780/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0516/test-artifacts/1632805780/distributedtestfiles-openjdk11-1.15.0-build.0516.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9647) MultiUserAuth: DataSerializer.Register throws when attempting to register a new DataSerializer.
[
https://issues.apache.org/jira/browse/GEODE-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421565#comment-17421565
]
Mark Hanson commented on GEODE-9647:
The solution appears to be to plumb the regionService down into the
DataSerializer class call to register. Doing so appears to alleviate the issue.
> MultiUserAuth: DataSerializer.Register throws when attempting to register a
> new DataSerializer.
> ---
>
> Key: GEODE-9647
> URL: https://issues.apache.org/jira/browse/GEODE-9647
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> When multiuserSecureModeEnabled is set, a user may attempt to register a
> DataSerializer, but will get the following error. The reason is that the
> PoolImpl needs credentials to authenticate against, which it does not have.
>
> {noformat}
> [warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
> instantiator on pool:java.lang.UnsupportedOperationException: Use Pool APIs
> for doing operations when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:34)
>
> at
> org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterDataSerializers(PoolManagerImpl.java:264)
>
> at
> org.apache.geode.internal.InternalDataSerializer.sendRegistrationMessageToServers(InternalDataSerializer.java:1197)
>
> at
> org.apache.geode.internal.InternalDataSerializer._register(InternalDataSerializer.java:1093)
>
> at
> org.apache.geode.internal.InternalDataSerializer.register(InternalDataSerializer.java:966)
> at org.apache.geode.DataSerializer.register(DataSerializer.java:2900)
> at
> org.apache.geode.management.internal.security.MultiUserAuthenticationDUnitTest.multiAuthenticatedView(MultiUserAuthenticationDUnitTest.java:152)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
>
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
>
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
>
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
>
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
>
> at com.intel
[jira] [Updated] (GEODE-9647) MultiUserAuth: DataSerializer.Register throws when attempting to register a new DataSerializer.
[
https://issues.apache.org/jira/browse/GEODE-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-9647:
---
Description:
When multiuserSecureModeEnabled is set, a user may attempt to register a
DataSerializer, but will get the following error. The reason is that the
PoolImpl needs credentials to authenticate against, which it does not have.
{noformat}
[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
instantiator on pool:java.lang.UnsupportedOperationException: Use Pool APIs for
doing operations when multiuser-secure-mode-enabled is set to true.
at
org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800)
at
org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:34)
at
org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterDataSerializers(PoolManagerImpl.java:264)
at
org.apache.geode.internal.InternalDataSerializer.sendRegistrationMessageToServers(InternalDataSerializer.java:1197)
at
org.apache.geode.internal.InternalDataSerializer._register(InternalDataSerializer.java:1093)
at
org.apache.geode.internal.InternalDataSerializer.register(InternalDataSerializer.java:966)
at org.apache.geode.DataSerializer.register(DataSerializer.java:2900)
at
org.apache.geode.management.internal.security.MultiUserAuthenticationDUnitTest.multiAuthenticatedView(MultiUserAuthenticationDUnitTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54) {noformat}
was:
When multiuserSecureModeEnabled is set, a user may attempt to register a
DataSerializer, but will get the following error. The reason is that the
PoolImpl needs credentials to authenticate against, which it does not have.
{noformat}
[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
instantiator on pool:[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error
registering instantiator on pool:java.lang.UnsupportedOperationException: Use
Pool APIs for doing operations when multiuser-secure-mode-enabled is set to
true. at
org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800)
at
org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:3
[jira] [Commented] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421564#comment-17421564 ] Geode Integration commented on GEODE-9038: -- Seen in [distributed-test-openjdk8 #216|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/216] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-results/distributedTest/1632825733/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-artifacts/1632825733/distributedtestfiles-openjdk8-1.15.0-build.0519.tgz]. > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Priority: Major > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting 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 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > 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) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9448) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException
[
https://issues.apache.org/jira/browse/GEODE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421562#comment-17421562
]
Geode Integration commented on GEODE-9448:
--
Seen in [distributed-test-openjdk11
#220|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/220]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-results/distributedTest/1632825846/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-artifacts/1632825846/distributedtestfiles-openjdk11-1.15.0-build.0519.tgz].
> CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with
> ConditionTimeoutException caused by TimeoutException
>
>
> Key: GEODE-9448
> URL: https://issues.apache.org/jira/browse/GEODE-9448
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kamilla Aslami
>Priority: Major
>
> This failure is similar to GEODE-8191 but the stack trace looks a bit
> different:
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but
> was:<[375]0> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108)
> Caused by:
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102)
> ... 5 more{noformat}
> I noticed that in the last failure reported on GEODE-8191 ([run
> #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/26]),
> the version of Awaitility was 4.0.3. In this failure, the version is 4.1.0,
> so this might be the reason why the stack traces are different.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9647) MultiUserAuth: DataSerializer.Register throws when attempting to register a new DataSerializer.
[
https://issues.apache.org/jira/browse/GEODE-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9647:
-
Labels: needsTriage (was: )
> MultiUserAuth: DataSerializer.Register throws when attempting to register a
> new DataSerializer.
> ---
>
> Key: GEODE-9647
> URL: https://issues.apache.org/jira/browse/GEODE-9647
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> When multiuserSecureModeEnabled is set, a user may attempt to register a
> DataSerializer, but will get the following error. The reason is that the
> PoolImpl needs credentials to authenticate against, which it does not have.
>
> {noformat}
> [warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
> instantiator on pool:[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error
> registering instantiator on pool:java.lang.UnsupportedOperationException: Use
> Pool APIs for doing operations when multiuser-secure-mode-enabled is set to
> true. at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800) at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:34)
> at
> org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterDataSerializers(PoolManagerImpl.java:264)
> at
> org.apache.geode.internal.InternalDataSerializer.sendRegistrationMessageToServers(InternalDataSerializer.java:1197)
> at
> org.apache.geode.internal.InternalDataSerializer._register(InternalDataSerializer.java:1093)
> at
> org.apache.geode.internal.InternalDataSerializer.register(InternalDataSerializer.java:966)
> at org.apache.geode.DataSerializer.register(DataSerializer.java:2900) at
> org.apache.geode.management.internal.security.MultiUserAuthenticationDUnitTest.multiAuthenticatedView(MultiUserAuthenticationDUnitTest.java:152)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at
> org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20) at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
> org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9647) MultiUserAuth: DataSerializer.Register throws when attempting to register a new DataSerializer.
Mark Hanson created GEODE-9647:
--
Summary: MultiUserAuth: DataSerializer.Register throws when
attempting to register a new DataSerializer.
Key: GEODE-9647
URL: https://issues.apache.org/jira/browse/GEODE-9647
Project: Geode
Issue Type: Bug
Components: core
Affects Versions: 1.15.0
Reporter: Mark Hanson
When multiuserSecureModeEnabled is set, a user may attempt to register a
DataSerializer, but will get the following error. The reason is that the
PoolImpl needs credentials to authenticate against, which it does not have.
{noformat}
[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error registering
instantiator on pool:[warn 2021/09/28 10:32:42.470 PDT tid=0x1] Error
registering instantiator on pool:java.lang.UnsupportedOperationException: Use
Pool APIs for doing operations when multiuser-secure-mode-enabled is set to
true. at
org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:800)
at
org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:34)
at
org.apache.geode.internal.cache.PoolManagerImpl.allPoolsRegisterDataSerializers(PoolManagerImpl.java:264)
at
org.apache.geode.internal.InternalDataSerializer.sendRegistrationMessageToServers(InternalDataSerializer.java:1197)
at
org.apache.geode.internal.InternalDataSerializer._register(InternalDataSerializer.java:1093)
at
org.apache.geode.internal.InternalDataSerializer.register(InternalDataSerializer.java:966)
at org.apache.geode.DataSerializer.register(DataSerializer.java:2900) at
org.apache.geode.management.internal.security.MultiUserAuthenticationDUnitTest.multiAuthenticatedView(MultiUserAuthenticationDUnitTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
at org.junit.rules.RunRules.evaluate(RunRules.java:20) at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
at
com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at
com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54) {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421556#comment-17421556
]
ASF subversion and git services commented on GEODE-6042:
Commit 9a4b302e8ddbaba507fd13bc42d4297c1f018b01 in geode-site's branch
refs/heads/asf-site from Alberto Bustamante
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=9a4b302 ]
Merge pull request #13 from Nordix/feature/GEODE-6042_1
GEODE-6042: Fix PMC link in doap file
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421557#comment-17421557
]
ASF GitHub Bot commented on GEODE-6042:
---
alb3rtobr merged pull request #13:
URL: https://github.com/apache/geode-site/pull/13
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6042) Change VMProvider import (commons.lang -> commons.lang3)
[
https://issues.apache.org/jira/browse/GEODE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421555#comment-17421555
]
ASF subversion and git services commented on GEODE-6042:
Commit 39ea9d930b9e742cd56fd30a08eff6edfe9c552a in geode-site's branch
refs/heads/asf-site from Alberto Bustamante
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=39ea9d9 ]
GEODE-6042: Fix PMC link in doap file
> Change VMProvider import (commons.lang -> commons.lang3)
>
>
> Key: GEODE-6042
> URL: https://issues.apache.org/jira/browse/GEODE-6042
> Project: Geode
> Issue Type: Bug
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The latest
> [commit|https://github.com/apache/geode/commit/7b252a628379d21fcafb34ce96357c434357a108]
> to {{develop}} doesn't compile because {{commons-lang}} was upgraded to
> {{commons-lang3}}, the import used by {{VMProvider}} is wrong.
> [CI builds|https://github.com/apache/geode/pull/2812] were completely green
> when the PR was opened, but the {{commons-lang}} version upgrade was merged
> to {{develop}} before the PR and, thus, the compilation fails.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9428) CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421525#comment-17421525
]
Geode Integration commented on GEODE-9428:
--
Seen in [acceptance-test-openjdk8
#213|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/213]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-results/acceptanceTest/1632828732/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0519/test-artifacts/1632828732/acceptancetestfiles-openjdk8-1.15.0-build.0519.tgz].
> CI Failure: PSetEXNativeRedisAcceptanceTest fails with CLUSTERDOWN error
>
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Hale Bales
>Priority: Major
>
> *This ticket tracks failures seen in NativeRedisAcceptanceTests due to
> non-Geode code. It is closed because no work will be done in the Geode
> project to fix this issue. If the issue becomes unbearable, a bug should be
> opened with Redis:
> [https://github.com/redis/redis/issues|https://github.com/redis/redis/issues*]*
> CI run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311]
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
> > testPSetEX FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>
[jira] [Commented] (GEODE-9570) Make sure registered interests will re-authenticate when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421498#comment-17421498 ] ASF subversion and git services commented on GEODE-9570: Commit 18758356ea2855533582a73599e88795e79db3d0 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1875835 ] GEODE-9570: make sure re-authentication works with registered interests (#6885) > Make sure registered interests will re-authenticate when auth expired > - > > Key: GEODE-9570 > URL: https://issues.apache.org/jira/browse/GEODE-9570 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9646) Update native redis tests to use version 6.x
[ https://issues.apache.org/jira/browse/GEODE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9646: -- Issue Type: Test (was: Improvement) > Update native redis tests to use version 6.x > - > > Key: GEODE-9646 > URL: https://issues.apache.org/jira/browse/GEODE-9646 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > > Some individual tests already use 6.2.4. For consistency we should use the > same version everywhere though. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9646) Update native redis tests to use version 6.x
Jens Deppe created GEODE-9646: - Summary: Update native redis tests to use version 6.x Key: GEODE-9646 URL: https://issues.apache.org/jira/browse/GEODE-9646 Project: Geode Issue Type: Improvement Reporter: Jens Deppe Some individual tests already use 6.2.4. For consistency we should use the same version everywhere though. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9646) Update native redis tests to use version 6.x
[ https://issues.apache.org/jira/browse/GEODE-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9646: -- Component/s: redis > Update native redis tests to use version 6.x > - > > Key: GEODE-9646 > URL: https://issues.apache.org/jira/browse/GEODE-9646 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Priority: Major > > Some individual tests already use 6.2.4. For consistency we should use the > same version everywhere though. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9642) Adding GW sender to allready initialized partitioned region is hanging in large cluster
[ https://issues.apache.org/jira/browse/GEODE-9642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9642: -- Labels: needsTriage pull-request-available (was: needsTriage) > Adding GW sender to allready initialized partitioned region is hanging in > large cluster > --- > > Key: GEODE-9642 > URL: https://issues.apache.org/jira/browse/GEODE-9642 > Project: Geode > Issue Type: Bug > Components: regions, wan >Affects Versions: 1.13.0, 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > We have observed, that adding parallel GW sender to existing (allready > initialized) partitioned regions is hanging. > In case command alter-region is executed (attaching GW sender to initialized > region), it is hanging in cluster with more then 20 servers. > Execution of command in cluster with 16 or less servers was successful, but > if cluster is expanded to 20 or more, command is hanging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9479) Document correct start up order in WAN setups
[ https://issues.apache.org/jira/browse/GEODE-9479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421245#comment-17421245 ] ASF subversion and git services commented on GEODE-9479: Commit cf33465495f65fb0ee47b8a32457078554b27cc5 in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf33465 ] GEODE-9479: Document receivers & regions start order (#6902) > Document correct start up order in WAN setups > - > > Key: GEODE-9479 > URL: https://issues.apache.org/jira/browse/GEODE-9479 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > I recently had to deal with an issue which root cause was the incorrect start > up order of a region an a receiver ([mail > thread|https://markmail.org/thread/qq32z5hducjoqndz]) > The correct order is: > - Senders > - Region > - Receivers > I have not been able to find this info in the user guide. I think a good > place could be the "Timing of Connections" sub-chapter on the "Overview of > Multi-site Caching" chapter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9479) Document correct start up order in WAN setups
[ https://issues.apache.org/jira/browse/GEODE-9479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-9479. - Fix Version/s: 1.15.0 Resolution: Fixed > Document correct start up order in WAN setups > - > > Key: GEODE-9479 > URL: https://issues.apache.org/jira/browse/GEODE-9479 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > I recently had to deal with an issue which root cause was the incorrect start > up order of a region an a receiver ([mail > thread|https://markmail.org/thread/qq32z5hducjoqndz]) > The correct order is: > - Senders > - Region > - Receivers > I have not been able to find this info in the user guide. I think a good > place could be the "Timing of Connections" sub-chapter on the "Overview of > Multi-site Caching" chapter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
