[jira] [Assigned] (GEODE-6293) Gfsh execute function command expects the function to have a result
[
https://issues.apache.org/jira/browse/GEODE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella reassigned GEODE-6293:
---
Assignee: Juan José Ramos Cassella
> Gfsh execute function command expects the function to have a result
> ---
>
> Key: GEODE-6293
> URL: https://issues.apache.org/jira/browse/GEODE-6293
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Juan José Ramos Cassella
>Priority: Major
>
> Functions with hasResult returning false cause gfsh to log this exception
> message:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- |
>
> server-1 | ERROR | Exception: Cannot return any result as the
> Function#hasResult() is false
> {noformat}
> That message is coming from `UserFunctionExecution.execute` which does:
> {noformat}
> List results = (List)
> execution.execute(function.getId()).getResult();
> {noformat}
> Here is the stack where that happens:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1333)
> at
> org.apache.geode.internal.cache.execute.NoResult.getResult(NoResult.java:56)
> at
> org.apache.geode.management.internal.cli.functions.UserFunctionExecution.execute(UserFunctionExecution.java:156)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:193)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:367)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:433)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:956)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:810)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Here is a potential fix that addresses the issue:
> {noformat}
> List results = null;
> ResultCollector rc = execution.execute(function.getId());
> if (function.hasResult()) {
> results = (List) rc.getResult();
> }
> {noformat}
> This fix causes gfsh to report an OK result:
> {noformat}
> gfsh>execute function --id=TestNoResultFunction --region=/data
> Member | Status | Message
> | -- | ---
> server-1 | OK | []
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6244: -- Labels: pull-request-available (was: ) > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755197#comment-16755197 ] ASF subversion and git services commented on GEODE-6244: Commit 352695fed0e8f1feb49a404cb6dbe902416aec1a in geode's branch refs/heads/feature/GEODE-6244b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=352695f ] GEODE-6244 Healthy member kicked out by Sick member when final-check fails The initial fix caused a problem that prevented election of a new membership coordinator in a certain case. The case was a view with nodes [A, B, C, D, E] where C was the coordinator. Node A had crashed and the crash had been detected by B. Node C then left the cluster, sending a Leave message to B. B's JoinLeave did not know about the HealthMonitor's decision that A was crashed and did not become the new coordinator. This commit makes B's JoinLeave pay attention to the crashed-member set in the HealthMonitor when deciding whether to become the membership coordinator for the cluster. > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 10m > Remaining Estimate: 0h > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales resolved GEODE-6276. - Resolution: Fixed Fix Version/s: 1.9.0 > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6326) versionTestConcurrentEventsOnEmptyRegion fails in CI in multiple configurations
[
https://issues.apache.org/jira/browse/GEODE-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755221#comment-16755221
]
ASF subversion and git services commented on GEODE-6326:
Commit 1e5e7dc5551d8ad94f15fc2d1efa9069b55b7e11 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1e5e7dc ]
GEODE-6326 versionTestConcurrentEventsOnEmptyRegion fails in CI in multiple
configurations
Added slow-GII processing to, I hope, cause the image-transfer problem
to happen more frequently.
Added a dump of region contents, including version stamps to give us
better artifacts to show that it is an image-transfer problem.
> versionTestConcurrentEventsOnEmptyRegion fails in CI in multiple
> configurations
> ---
>
> Key: GEODE-6326
> URL: https://issues.apache.org/jira/browse/GEODE-6326
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Assignee: Bruce Schuchardt
>Priority: Major
>
> DistributedAckOverflowRegionCCEDUnitTest.versionTestConcurrentEventsOnEmptyRegion
> failed in CI:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/335]
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0375/test-results/distributedTest/1548465595/classes/org.apache.geode.cache30.DistributedAckOverflowRegionCCEDUnitTest.html#testConcurrentEventsOnEmptyRegion]:
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition with alias 'Wait for
> the members to eventually be consistent' didn't complete within 300 seconds
> because assertion condition defined as a lambda expression in
> org.apache.geode.cache30.MultiVMRegionTestCase that uses
> org.apache.geode.test.dunit.VM,
> org.apache.geode.test.dunit.VMorg.apache.geode.test.dunit.VM,
> org.apache.geode.test.dunit.VMorg.apache.geode.test.dunit.VM [r2 contents are
> not consistent with r1 for cckey2] expected:<"ccvalue[-100586808]"> but
> was:<"ccvalue[1574152144]">.
> 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:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.versionTestConcurrentEventsOnEmptyRegion(MultiVMRegionTestCase.java:8282)
> at
> org.apache.geode.cache30.DistributedAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion(DistributedAckRegionCCEDUnitTest.java:421)
> 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.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 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 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.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitT
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755238#comment-16755238 ] ASF subversion and git services commented on GEODE-6294: Commit 19edb37d1ba85b02c3c3fb37094758ed3a334e56 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=19edb37 ] GEODE-6294 Document new disable-jmx property > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755246#comment-16755246 ] ASF subversion and git services commented on GEODE-6294: Commit 68608a99e85ec19280de76e45faf72b0eba3a93c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68608a9 ] GEODE-6294 Document new disable-jmx property (#3128) * GEODE-6294 Document new disable-jmx property * GEODE-6294 Better wording for disable-jmx property description * GEODE-6294 Empty commit to cause re-run of failed CI tests * GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755243#comment-16755243 ] ASF subversion and git services commented on GEODE-6294: Commit 68608a99e85ec19280de76e45faf72b0eba3a93c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68608a9 ] GEODE-6294 Document new disable-jmx property (#3128) * GEODE-6294 Document new disable-jmx property * GEODE-6294 Better wording for disable-jmx property description * GEODE-6294 Empty commit to cause re-run of failed CI tests * GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755242#comment-16755242 ] ASF subversion and git services commented on GEODE-6294: Commit 68608a99e85ec19280de76e45faf72b0eba3a93c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68608a9 ] GEODE-6294 Document new disable-jmx property (#3128) * GEODE-6294 Document new disable-jmx property * GEODE-6294 Better wording for disable-jmx property description * GEODE-6294 Empty commit to cause re-run of failed CI tests * GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755244#comment-16755244 ] ASF subversion and git services commented on GEODE-6294: Commit 68608a99e85ec19280de76e45faf72b0eba3a93c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68608a9 ] GEODE-6294 Document new disable-jmx property (#3128) * GEODE-6294 Document new disable-jmx property * GEODE-6294 Better wording for disable-jmx property description * GEODE-6294 Empty commit to cause re-run of failed CI tests * GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755241#comment-16755241 ] ASF subversion and git services commented on GEODE-6294: Commit f8007e4538070936358b27e01d00e3e170e9f92e in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8007e4 ] GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755245#comment-16755245 ] ASF subversion and git services commented on GEODE-6294: Commit 68608a99e85ec19280de76e45faf72b0eba3a93c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=68608a9 ] GEODE-6294 Document new disable-jmx property (#3128) * GEODE-6294 Document new disable-jmx property * GEODE-6294 Better wording for disable-jmx property description * GEODE-6294 Empty commit to cause re-run of failed CI tests * GEODE-6294 Empty commit to re-run failing tests unassociated with this PR > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755240#comment-16755240 ] ASF subversion and git services commented on GEODE-6294: Commit 9ab7ffe84fd5eb2debd9cacc7890b5a56d330cf9 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9ab7ffe ] GEODE-6294 Empty commit to cause re-run of failed CI tests > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755239#comment-16755239 ] ASF subversion and git services commented on GEODE-6294: Commit 4d23f68b57aaa7560392561a46ff4d292aee9b0e in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4d23f68 ] GEODE-6294 Better wording for disable-jmx property description > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6185) Java Api for creating region requires authentication and authorization
[ https://issues.apache.org/jira/browse/GEODE-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755275#comment-16755275 ] ASF subversion and git services commented on GEODE-6185: Commit 3493e8c8bfab0b7373f517f78762ea0921d7ef3c in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3493e8c ] GEODE-6185: management rest end point returns correct status code and message Co-authored-by: Jens Deppe > Java Api for creating region requires authentication and authorization > -- > > Key: GEODE-6185 > URL: https://issues.apache.org/jira/browse/GEODE-6185 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Time Spent: 8h 50m > Remaining Estimate: 0h > > Users accessing the createRegion api will need to have the same privilege as > user who can execute the create region command and provide authentication > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6174) Create Region REST API
[ https://issues.apache.org/jira/browse/GEODE-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755276#comment-16755276 ] ASF subversion and git services commented on GEODE-6174: Commit c97edf9ae9ccf8964e10bf4f9b22cd853fae6d1f in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c97edf9 ] GEODE-6174: change refid to type and make the default type to be PARTITION (#3130) Co-authored-by: Peter Tran * change refid to type for better UX * add a common config validator interface and use that to validate RegionConfig > Create Region REST API > -- > > Key: GEODE-6174 > URL: https://issues.apache.org/jira/browse/GEODE-6174 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Time Spent: 3h 10m > Remaining Estimate: 0h > > I want to be able to interact with the cluster without having to be on the > cluster in order to effect the configuration. Either as a developer, I want > to develop code in my IDE and as part of developing that code, I need to > create regions. Or as a data operator, I need to perform configurations on > the cluster and I want to interact with the cluster. > > As a Developer > I want to create a region in the cluster using the JAVA API on the cluster > when I am not located on the cluster (I do not need to be be on a node on the > cluster) > when I am authenticated and authorized for create region > So that a region is created on the cluster > So that I can put and get data in that region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6325) Bad comparison in GemFireStatSamplerIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6325:
--
Labels: pull-request-available (was: )
> Bad comparison in GemFireStatSamplerIntegrationTest
> ---
>
> Key: GEODE-6325
> URL: https://issues.apache.org/jira/browse/GEODE-6325
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
>
> {{GemFireStatSamplerIntegrationTest}} insists that the stat sampler start
> time be less than the current time. Should be less than or equal.
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/251
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0374/test-results/integrationTest/1548476760/
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics(GemFireStatSamplerIntegrationTest.java:125)
> 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.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 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
[jira] [Created] (GEODE-6333) Add jetty-server dependency to geode-core
nabarun created GEODE-6333:
--
Summary: Add jetty-server dependency to geode-core
Key: GEODE-6333
URL: https://issues.apache.org/jira/browse/GEODE-6333
Project: Geode
Issue Type: Bug
Components: benchmarks
Reporter: nabarun
Adding compile('org.eclipse.jetty:jetty-server:' + project.'jetty.version') to
geode-core gradle.build
This was done to prevent issues of class not found error when geode-core
dependencies are added as a local maven dependency.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6334) CachePerfStats gets and puts may wrap to negative values
Kirk Lund created GEODE-6334: Summary: CachePerfStats gets and puts may wrap to negative values Key: GEODE-6334 URL: https://issues.apache.org/jira/browse/GEODE-6334 Project: Geode Issue Type: Bug Components: statistics Reporter: Kirk Lund CachePerfStats gets and puts are implemented as IntCounters. They will wrap to negative values when incremented beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6335) StatSamplerStats jvmPauses may wrap to negative value
Kirk Lund created GEODE-6335: Summary: StatSamplerStats jvmPauses may wrap to negative value Key: GEODE-6335 URL: https://issues.apache.org/jira/browse/GEODE-6335 Project: Geode Issue Type: Bug Components: statistics Reporter: Kirk Lund StatSamplerStats jvmPauses is implemented as IntCounter. It will wrap to negative value when incremented beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6334) CachePerfStats gets and puts may wrap to negative values
[ https://issues.apache.org/jira/browse/GEODE-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-6334: Assignee: Kirk Lund > CachePerfStats gets and puts may wrap to negative values > > > Key: GEODE-6334 > URL: https://issues.apache.org/jira/browse/GEODE-6334 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > CachePerfStats gets and puts are implemented as IntCounters. They will wrap > to negative values when incremented beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6336) gfsh create region does not support multiple configurations for the same region name
Darrel Schneider created GEODE-6336: --- Summary: gfsh create region does not support multiple configurations for the same region name Key: GEODE-6336 URL: https://issues.apache.org/jira/browse/GEODE-6336 Project: Geode Issue Type: Bug Components: gfsh Reporter: Darrel Schneider gfsh create region has group support but it does not allow the same region name to be created with different configurations in different groups. Geode has support for different configurations for the same region name in the same cluster. For example you can have some members define a PartitionedRegion as an accessor (it stores no data) and others that define it as a store (it actually stores data for the region). For replicas you can have some members be persistent, others non-persistent, and others be empty proxies. Cluster config does have group support so the way this was supposed to work was that each group could define the region in its own way and would not fail saying it was already created in another group. If a member decides to join multiple groups then it is an error if the same name is defined in more than one group. As it is, you currently can not use gfsh to create regions in supported configurations. You would need to disable cluster config and instead define you regions with your own xml files or using apis each time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6335) StatSamplerStats jvmPauses may wrap to negative value
[ https://issues.apache.org/jira/browse/GEODE-6335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-6335: Assignee: Kirk Lund > StatSamplerStats jvmPauses may wrap to negative value > - > > Key: GEODE-6335 > URL: https://issues.apache.org/jira/browse/GEODE-6335 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > StatSamplerStats jvmPauses is implemented as IntCounter. It will wrap to > negative value when incremented beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6333) Add jetty-server dependency to geode-core
[
https://issues.apache.org/jira/browse/GEODE-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6333:
--
Labels: pull-request-available (was: )
> Add jetty-server dependency to geode-core
> -
>
> Key: GEODE-6333
> URL: https://issues.apache.org/jira/browse/GEODE-6333
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
>
> Adding compile('org.eclipse.jetty:jetty-server:' + project.'jetty.version')
> to geode-core gradle.build
> This was done to prevent issues of class not found error when geode-core
> dependencies are added as a local maven dependency.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6294) Add disable-jmx configuration property to disable JMX
[ https://issues.apache.org/jira/browse/GEODE-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-6294. -- Resolution: Fixed Configuration property disable-jmx is now fully documented. > Add disable-jmx configuration property to disable JMX > - > > Key: GEODE-6294 > URL: https://issues.apache.org/jira/browse/GEODE-6294 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Add disable-jmx configuration property to disable JMX. This option is boolean > and will have a false value by default. Setting it to true will prevent Geode > from creating and using MBeans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4036) ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one
[ https://issues.apache.org/jira/browse/GEODE-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-4036. - Resolution: Cannot Reproduce This has been open and unaddressed for roughly 15 months now, so closing out as part of tidying. If it's encountered again, please open a new ticket with more detailed information. > ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one > -- > > Key: GEODE-4036 > URL: https://issues.apache.org/jira/browse/GEODE-4036 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mark Hanson >Priority: Major > > ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one > specifically seen on a System.InvalidCastException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4036) ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one
[ https://issues.apache.org/jira/browse/GEODE-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-4036. --- > ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one > -- > > Key: GEODE-4036 > URL: https://issues.apache.org/jira/browse/GEODE-4036 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mark Hanson >Priority: Major > > ExceptionTypes.hpp:210 dereferencing inner exception when there isn't one > specifically seen on a System.InvalidCastException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6314) CI: Build version should only be rolled, and should always be rolled, at the Build step
[ https://issues.apache.org/jira/browse/GEODE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755448#comment-16755448 ] ASF subversion and git services commented on GEODE-6314: Commit 5a20ec02fc9197fe347859e515439aea6483f9f2 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a20ec0 ] GEODE-6314 Only rolling build-version semver at build time (#3113) * GEODE-6314 Only rolling build-version semver at build time * Upload new verison immediately * Use consistent 'pre' for the version id * Fix the 'get' for Windows, Publish, Benchmark jobs Co-authored-by: Patrick Rhomberg Co-authored-by: Robert Houghton * fix tabature for concourse happiness Co-authored-by: Patrick Rhomberg Co-authored-by: Robert Houghton > CI: Build version should only be rolled, and should always be rolled, at the > Build step > --- > > Key: GEODE-6314 > URL: https://issues.apache.org/jira/browse/GEODE-6314 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the build ID is bumped also at publish as well as Build, and Build > only bumps when it is successful. In its role as a single, meaningful > identifier, it should always be rolled at Build, and only there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6314) CI: Build version should only be rolled, and should always be rolled, at the Build step
[ https://issues.apache.org/jira/browse/GEODE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755447#comment-16755447 ] ASF subversion and git services commented on GEODE-6314: Commit 5a20ec02fc9197fe347859e515439aea6483f9f2 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a20ec0 ] GEODE-6314 Only rolling build-version semver at build time (#3113) * GEODE-6314 Only rolling build-version semver at build time * Upload new verison immediately * Use consistent 'pre' for the version id * Fix the 'get' for Windows, Publish, Benchmark jobs Co-authored-by: Patrick Rhomberg Co-authored-by: Robert Houghton * fix tabature for concourse happiness Co-authored-by: Patrick Rhomberg Co-authored-by: Robert Houghton > CI: Build version should only be rolled, and should always be rolled, at the > Build step > --- > > Key: GEODE-6314 > URL: https://issues.apache.org/jira/browse/GEODE-6314 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the build ID is bumped also at publish as well as Build, and Build > only bumps when it is successful. In its role as a single, meaningful > identifier, it should always be rolled at Build, and only there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6329) gfsh show missing-disk-stores shows disk stores that aren't missing
[ https://issues.apache.org/jira/browse/GEODE-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6329: -- Labels: pull-request-available (was: ) > gfsh show missing-disk-stores shows disk stores that aren't missing > --- > > Key: GEODE-6329 > URL: https://issues.apache.org/jira/browse/GEODE-6329 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > The gfsh show missing-disk-stores command is showing disk stores that aren't > actually missing. > To reproduce > - Start 4 servers with a persistent PR with redundancy 1 > - Stop 2 servers, rebalancing in between > - Restart the 2 servers and wait for recovery to complete > Gfsh reports one of the disk stores of the first stopped server as missing. > There appear to be few problems here. The JMX listMissingDiskStores removes > disk stores that are reported as present by other members, however the gfsh > command is not using the same logic, so it's reporting the same disk stores > as missing even if they are reported as present. > The JMX command also can fail here, however, because if a member has a disk > store but 0 buckets, the member is not reporting the disk store as present. > Finally, the missing disk stores reported by individual nodes come from the > persistent view of each bucket. Geode should be updating the persistent view > when each member restarts. Therefore the "missing" disk store should have > been removed from the persistent view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6337) Rolling upgrade test fails on JDK11 in CI (sometimes)
Bill Burcham created GEODE-6337:
---
Summary: Rolling upgrade test fails on JDK11 in CI (sometimes)
Key: GEODE-6337
URL: https://issues.apache.org/jira/browse/GEODE-6337
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Bill Burcham
In this build:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/333
{{RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer()}}
fails, apparently trying to start up Geode version 1.3.0.
Have a look at the first two errors in the test output:
{noformat}
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> testRollLocatorsWithOldServer[from_v130] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.VM$$Lambda$157/0x000840246c40.run in VM 1
running on Host f634ce7e984c with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
at org.apache.geode.test.dunit.VM.bounce(VM.java:497)
at org.apache.geode.test.dunit.VM.bounce(VM.java:476)
at
org.apache.geode.test.dunit.internal.DUnitHost.getVM(DUnitHost.java:85)
at
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer(RollingUpgradeRollLocatorsWithOldServer.java:39)
Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header; nested
exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:236)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:209)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:161)
at com.sun.proxy.$Proxy40.executeMethodOnObject(Unknown Source)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
... 4 more
Caused by:
java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:272)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:222)
... 9 more
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
f634ce7e984c with 4 VMs
Caused by:
java.lang.IllegalStateException: VM not available: VM 1 running on Host
f634ce7e984c with 4 VMs
org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> testRollLocatorsWithOldServer[from_v150] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.VM$$Lambda$156/0x000840247040.call in VM 1
running on Host f634ce7e984c with 4 VMs
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
nested exception is:
java.net.ConnectException: Connection refused (Connection
refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
f634ce7e984c with 4 VMs
Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
nested exception is:
java.net.ConnectException: Connection refused (Connection
refused)
Caused by:
java.net.ConnectException: Connection refused (Connection refused)
{noformat}
Notice that the first exception is caused by an EOF whereas the second one is
"connection refused".
Dunno what version of Geode was running on that JVM when the attempt to bounce
to 1.3.0 was made. But you can see in the test output that it wasn't one of
these:
from_v130
from_v150
from_v160
from_v170
from_v180
We also noticed this in stderr. Dunno if it's important:
{noformat}
Geode version 140 is incompatible with Java 9 and higher. Skipping this
version.
[vm0_v100] WARNING: An illegal reflective access operation has occurred
[vm0_v100] WARNING: Illegal reflective access by
org.apache.geode.internal.shared.NativeCalls
(file:/home/geode/.gradle/caches/modules-2/files-2.1/org.apache.geode/geode-core/1.0.0-incubating/28ed9510a84bfd48f1f01ac4bb6f2d5717fc01f/geode-core-1.0.0-incubating.jar)
to field java.util.Collections$UnmodifiableMap.m
[vm0_v100] WARNING: Please consider reporting this to the maintainers of
org.apache.geode.internal.shared.NativeCalls
[vm0_v100] WARNING: Use --illegal-access=warn to enable warnings of further
illegal reflective access operations
[vm0_v100] WARNING: All illegal access operations will be denied i
[jira] [Updated] (GEODE-6337) Rolling upgrade test fails on JDK11 in CI (sometimes)
[
https://issues.apache.org/jira/browse/GEODE-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-6337:
Labels: jdk11 (was: )
> Rolling upgrade test fails on JDK11 in CI (sometimes)
> -
>
> Key: GEODE-6337
> URL: https://issues.apache.org/jira/browse/GEODE-6337
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.9.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: jdk11
>
> In this build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/333
> {{RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer()}}
> fails, apparently trying to start up Geode version 1.3.0.
> Have a look at the first two errors in the test output:
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> > testRollLocatorsWithOldServer[from_v130] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$157/0x000840246c40.run in VM 1
> running on Host f634ce7e984c with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
> at org.apache.geode.test.dunit.VM.bounce(VM.java:497)
> at org.apache.geode.test.dunit.VM.bounce(VM.java:476)
> at
> org.apache.geode.test.dunit.internal.DUnitHost.getVM(DUnitHost.java:85)
> at
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer(RollingUpgradeRollLocatorsWithOldServer.java:39)
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:236)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:209)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:161)
> at com.sun.proxy.$Proxy40.executeMethodOnObject(Unknown Source)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
> ... 4 more
> Caused by:
> java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:272)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:222)
> ... 9 more
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> f634ce7e984c with 4 VMs
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 1 running on
> Host f634ce7e984c with 4 VMs
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> > testRollLocatorsWithOldServer[from_v150] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$156/0x000840247040.call in VM 1
> running on Host f634ce7e984c with 4 VMs
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection
> refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> f634ce7e984c with 4 VMs
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection
> refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> Notice that the first exception is caused by an EOF whereas the second one is
> "connection refused".
> Dunno what version of Geode was running on that JVM when the attempt to
> bounce to 1.3.0 was made. But you can see in the test output that it wasn't
> one of these:
> from_v130
> from_v150
> from_v160
> from_v170
> from_v180
> We also noticed this in stderr. Dunno if it's important:
> {noformat}
> Geode version 140 is incompatible with Java 9 and higher. Skipping this
> version.
> [vm0_v100] WARNING: An illegal reflective access operation has occurred
> [vm0_v100] WARNING: Illegal reflective access by
> org.apache.geode.internal.shared.NativeCalls
> (file:/home/geode/.gradle/caches/modules-2/files-2.1/org.apache.geode/geode-core/1.0.0-i
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755497#comment-16755497 ] ASF subversion and git services commented on GEODE-2113: Commit 33077b3dab41260c70cece5b4f7ff1c42501b01c in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=33077b3 ] GEODE-2113 Implement SSL over NIO This fixes several bugs in the original implementation of SSL over NIO. Notably there were buffer handling problems in MsgReader and the NioFilters. This new commit includes code coverage for these classes in new tests. Original commit message: This removes old-I/O use in TCPConduit peer-to-peer communications. This was used for SSL/TLS secure commuications but Java has had an SSLEngine implementation that allows you to implement secure communications on new-I/O SocketChannels or any other transport mechanism. A new NioSSLEngine class wraps the JDK's SSLEngine and provides the SSL handshake as well as encryption/decryption of messages. SocketCreator performs the SSL handshake and returns a NioSslEngine that TCPConduit then uses for messaging. The SSL handshake needs to be done in Connection.java now because the ByteBuffer used to do the handshake is also used for reading messages in Receivers. Because of this the Handshake pool in TCPConduit became obsolete and I deleted it. I've also done a lot of cleanup of compilation warnings in Connection.java and removed references to "NIO". The primary SSL/TLS changes in that class are in writeFully (renamed from nioWriteFully) and processBuffer (renamed from processNIOBuffer). While testing I noticed some places where we're creating non-daemon threads that were keeping DUnit ChildVM processes from exiting. I've changed these places to use daemon threads. Very few threads in Geode should be non-daemon. Porting client/server to use NioSSLEngine will be done under a separate ticket and a different version of NioEngine may be created to secure UDP messaging. > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: messaging >Reporter: Addison >Assignee: Bruce Schuchardt >Priority: Major > Labels: SmallFeature, pull-request-available > Fix For: 1.9.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6337) Rolling upgrade test fails on JDK11 in CI (sometimes)
[
https://issues.apache.org/jira/browse/GEODE-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-6337:
Affects Version/s: 1.9.0
> Rolling upgrade test fails on JDK11 in CI (sometimes)
> -
>
> Key: GEODE-6337
> URL: https://issues.apache.org/jira/browse/GEODE-6337
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.9.0
>Reporter: Bill Burcham
>Priority: Major
>
> In this build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/333
> {{RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer()}}
> fails, apparently trying to start up Geode version 1.3.0.
> Have a look at the first two errors in the test output:
> {noformat}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> > testRollLocatorsWithOldServer[from_v130] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$157/0x000840246c40.run in VM 1
> running on Host f634ce7e984c with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
> at org.apache.geode.test.dunit.VM.bounce(VM.java:497)
> at org.apache.geode.test.dunit.VM.bounce(VM.java:476)
> at
> org.apache.geode.test.dunit.internal.DUnitHost.getVM(DUnitHost.java:85)
> at
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer.testRollLocatorsWithOldServer(RollingUpgradeRollLocatorsWithOldServer.java:39)
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:236)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:209)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:161)
> at com.sun.proxy.$Proxy40.executeMethodOnObject(Unknown Source)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:530)
> ... 4 more
> Caused by:
> java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:272)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:222)
> ... 9 more
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> f634ce7e984c with 4 VMs
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 1 running on
> Host f634ce7e984c with 4 VMs
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollLocatorsWithOldServer
> > testRollLocatorsWithOldServer[from_v150] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$156/0x000840247040.call in VM 1
> running on Host f634ce7e984c with 4 VMs
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection
> refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> f634ce7e984c with 4 VMs
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.4;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection
> refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> Notice that the first exception is caused by an EOF whereas the second one is
> "connection refused".
> Dunno what version of Geode was running on that JVM when the attempt to
> bounce to 1.3.0 was made. But you can see in the test output that it wasn't
> one of these:
> from_v130
> from_v150
> from_v160
> from_v170
> from_v180
> We also noticed this in stderr. Dunno if it's important:
> {noformat}
> Geode version 140 is incompatible with Java 9 and higher. Skipping this
> version.
> [vm0_v100] WARNING: An illegal reflective access operation has occurred
> [vm0_v100] WARNING: Illegal reflective access by
> org.apache.geode.internal.shared.NativeCalls
> (file:/home/geode/.gradle/caches/modules-2/files-2.1/org.apache.geode/geode-core/1.0.0-incubating/28ed9510a84bfd48f
[jira] [Updated] (GEODE-6334) CachePerfStats operation count stats may wrap to negative values
[ https://issues.apache.org/jira/browse/GEODE-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-6334: - Summary: CachePerfStats operation count stats may wrap to negative values (was: CachePerfStats gets and puts may wrap to negative values) > CachePerfStats operation count stats may wrap to negative values > > > Key: GEODE-6334 > URL: https://issues.apache.org/jira/browse/GEODE-6334 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > CachePerfStats gets and puts are implemented as IntCounters. They will wrap > to negative values when incremented beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6334) CachePerfStats operation count stats may wrap to negative values
[ https://issues.apache.org/jira/browse/GEODE-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-6334: - Description: Many CachePerfStats operation count stats are implemented as IntCounters including puts and gets. They will wrap to negative values when incremented beyond Integer.MAX_VALUE. (was: CachePerfStats gets and puts are implemented as IntCounters. They will wrap to negative values when incremented beyond Integer.MAX_VALUE.) > CachePerfStats operation count stats may wrap to negative values > > > Key: GEODE-6334 > URL: https://issues.apache.org/jira/browse/GEODE-6334 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Many CachePerfStats operation count stats are implemented as IntCounters > including puts and gets. They will wrap to negative values when incremented > beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6244) Healthy member kicked out by Sick member when final-check fails
[ https://issues.apache.org/jira/browse/GEODE-6244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755537#comment-16755537 ] ASF subversion and git services commented on GEODE-6244: Commit 352695fed0e8f1feb49a404cb6dbe902416aec1a in geode's branch refs/heads/feature/GEODE-6244b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=352695f ] GEODE-6244 Healthy member kicked out by Sick member when final-check fails The initial fix caused a problem that prevented election of a new membership coordinator in a certain case. The case was a view with nodes [A, B, C, D, E] where C was the coordinator. Node A had crashed and the crash had been detected by B. Node C then left the cluster, sending a Leave message to B. B's JoinLeave did not know about the HealthMonitor's decision that A was crashed and did not become the new coordinator. This commit makes B's JoinLeave pay attention to the crashed-member set in the HealthMonitor when deciding whether to become the membership coordinator for the cluster. > Healthy member kicked out by Sick member when final-check fails > --- > > Key: GEODE-6244 > URL: https://issues.apache.org/jira/browse/GEODE-6244 > Project: Geode > Issue Type: New Feature > Components: membership >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, > 1.7.0, 1.8.0 >Reporter: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I observed this in a user's logs & can't include artifacts: Clients were > herding to one server when another server was being slow to return results. > The clients caused the server to run out of file descriptors because the > descriptor limit was set pretty low. When that happened the server had > trouble forming an outgoing tcp/ip connection to another server. It tried > using MembershipManager.verifyMember() which also failed to connect to the > other server. When that happened it sent a RemoveMessage to the locators and > several of the other servers, including the one it couldn't connect to. That > server immediately shut itself down. > MembershipManager.verifyMember() is documented to only initiate suspect > processing on the target, not initiate immediate removal. This is supposed > to be done so that some other process (i.e., the membership coordinator) will > do additional checking on the suspect in case the initiator is itself sick. > That was the case in this situation. > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends RemoveMember message to locators and serverB > serverB shuts itself down (ForcedDisconnect) > The behavior should instead be > serverA unable to connect to serverB > serverA performs tcp/ip check in verifyMember > serverA's tcp/ip check fails (it's out of file descriptors, duh) > serverA sends SuspectMember message to locators & other servers > coordinator performs tcp/ip and heartbeat check on the suspect > coordinator determines suspect is available > This is all due to the checkMember call in GMSMembershipManager passing > _true_ for the _initiateRemoval_ parameter. It should be passing _false_. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6334) CachePerfStats operation count stats may wrap to negative values
[ https://issues.apache.org/jira/browse/GEODE-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6334: -- Labels: pull-request-available (was: ) > CachePerfStats operation count stats may wrap to negative values > > > Key: GEODE-6334 > URL: https://issues.apache.org/jira/browse/GEODE-6334 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > Many CachePerfStats operation count stats are implemented as IntCounters > including puts and gets. They will wrap to negative values when incremented > beyond Integer.MAX_VALUE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6325) Bad comparison in GemFireStatSamplerIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755540#comment-16755540
]
ASF subversion and git services commented on GEODE-6325:
Commit 054687a17ccd06ce38f73a59cc4310dd9b5b1bd5 in geode's branch
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=054687a ]
Merge pull request #3133 from demery-pivotal/feature/GEODE-6325
GEODE-6325: Clarify start time assertion
> Bad comparison in GemFireStatSamplerIntegrationTest
> ---
>
> Key: GEODE-6325
> URL: https://issues.apache.org/jira/browse/GEODE-6325
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{GemFireStatSamplerIntegrationTest}} insists that the stat sampler start
> time be less than the current time. Should be less than or equal.
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/251
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0374/test-results/integrationTest/1548476760/
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics(GemFireStatSamplerIntegrationTest.java:125)
> 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.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 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHan
[jira] [Commented] (GEODE-6325) Bad comparison in GemFireStatSamplerIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755538#comment-16755538
]
ASF subversion and git services commented on GEODE-6325:
Commit 556ac6e76ab64d2c9a20ad534305dda6907a90ef in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=556ac6e ]
GEODE-6325: Clarify start time assertion
- Convert all assertions to AssertJ and make them more informative.
- Convert all polling loops to Awaitility.
Co-authored-by: Dale Emery
Co-authored-by: Michael Oleske
> Bad comparison in GemFireStatSamplerIntegrationTest
> ---
>
> Key: GEODE-6325
> URL: https://issues.apache.org/jira/browse/GEODE-6325
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{GemFireStatSamplerIntegrationTest}} insists that the stat sampler start
> time be less than the current time. Should be less than or equal.
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/251
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0374/test-results/integrationTest/1548476760/
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics(GemFireStatSamplerIntegrationTest.java:125)
> 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.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 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLo
[jira] [Commented] (GEODE-6325) Bad comparison in GemFireStatSamplerIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16755539#comment-16755539
]
ASF subversion and git services commented on GEODE-6325:
Commit 054687a17ccd06ce38f73a59cc4310dd9b5b1bd5 in geode's branch
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=054687a ]
Merge pull request #3133 from demery-pivotal/feature/GEODE-6325
GEODE-6325: Clarify start time assertion
> Bad comparison in GemFireStatSamplerIntegrationTest
> ---
>
> Key: GEODE-6325
> URL: https://issues.apache.org/jira/browse/GEODE-6325
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{GemFireStatSamplerIntegrationTest}} insists that the stat sampler start
> time be less than the current time. Should be less than or equal.
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/251
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0374/test-results/integrationTest/1548476760/
> {noformat}
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics(GemFireStatSamplerIntegrationTest.java:125)
> 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.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 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHan
