[jira] [Commented] (GEODE-5898) Cache methods do not throw CacheClosedException after closed
[
https://issues.apache.org/jira/browse/GEODE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656263#comment-16656263
]
ASF subversion and git services commented on GEODE-5898:
Commit 91f0af515dc62c9dc443f08c70111af8b7c3 in geode-native's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=91f0af5 ]
GEODE-5898: Throw CacheClosedException after Cache is closed.
* Adds unit test to assert.
> Cache methods do not throw CacheClosedException after closed
>
>
> Key: GEODE-5898
> URL: https://issues.apache.org/jira/browse/GEODE-5898
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Despite the claim in the API docs that all methods on {{Cache}} through
> {{CacheClosedException}} many of the methods do not. Same had in previous
> versions but through refactoring they were lost. No tests asserted this
> expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5209) Code Coverage Integration
[ https://issues.apache.org/jira/browse/GEODE-5209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-5209. - Resolution: Fixed Fix Version/s: 1.8.0 > Code Coverage Integration > - > > Key: GEODE-5209 > URL: https://issues.apache.org/jira/browse/GEODE-5209 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > _As_ a Geode-Native contributor/developer > _I want to_ use code coverage tools > _So that_ see what code is currently covered by our unit and integration tests > > We will want to add this to CMake so we can run code coverage analysis on > demand. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-2606) Source distribution needs missing files
[
https://issues.apache.org/jira/browse/GEODE-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-2606:
---
Assignee: (was: Ryan McMahon)
> Source distribution needs missing files
> ---
>
> Key: GEODE-2606
> URL: https://issues.apache.org/jira/browse/GEODE-2606
> Project: Geode
> Issue Type: Sub-task
> Components: build, native client
>Reporter: Anthony Baker
>Priority: Major
>
> The source distribution generated by
> {{cpack --config CPackSourceConfig.cmake}}
> only includes files from the {{src}} directory. It should include all files
> from the root directory.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
[ https://issues.apache.org/jira/browse/GEODE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656122#comment-16656122 ] ASF subversion and git services commented on GEODE-5872: Commit 6d95888b9d13a6657536d0fa016f58d0ea45a80b in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d95888 ] GEODE-5872: Ignoring tests that are losing assertion failures Tests in PersistentColocatedPartitionedRegionDUnitTest had return statements that lost the assertion failure. These tests were previously passing because they got awailitity timeouts before the test timeout. Now the tests fail, but only because the timeouts are longer. Ignoring them for this PR. > Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions > -- > > Key: GEODE-5872 > URL: https://issues.apache.org/jira/browse/GEODE-5872 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > There are several tests in PersistentColocatedPartitionedRegionDUnitTest that > are have returns inside finally blocks. The effect of this is that the tests > are actually ignoring any assertion failures. > In practice, these tests fail with Awailility timeouts all the time. With my > changes for GEODE-5424, the tests now timeout because I increased the > awailitity timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5787) Support graceful bouncing DUnit VMs on windows
[ https://issues.apache.org/jira/browse/GEODE-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656124#comment-16656124 ] ASF subversion and git services commented on GEODE-5787: Commit 3abbe30d8c224f397f6f0439d48fc0ecde703ab8 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Sai Boorlagadda [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3abbe30 ] Merge branch 'develop' into feature/GEODE-5787-dunit-internal > Support graceful bouncing DUnit VMs on windows > -- > > Key: GEODE-5787 > URL: https://issues.apache.org/jira/browse/GEODE-5787 > Project: Geode > Issue Type: New Feature > Components: tests >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Process.destroy is not graceful on windows and causes distributed system to > get into suspect processing and network partition when used in DUnit to > restart VMs. > There were existing JDK > [bugs|https://bugs.openjdk.java.net/browse/JDK-8056139] open requesting for > supporting graceful destroy for Windows. > Underlying native implementation on Linux can take advantage of SIGTERM vs > SIGKILL and JDK support process.destroy and process.destroyForcibly, where as > on Windows this differentiation is not possible so its unlikely that we will > see JDK support for graceful destroy. > A better approach would be to invoke 'System.exit( n )' using VM.invoke. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
[
https://issues.apache.org/jira/browse/GEODE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656121#comment-16656121
]
ASF subversion and git services commented on GEODE-5863:
Commit 61014b2f20f4e57e59bb2ffe2e9968545ba0e37a in geode's branch
refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=61014b2 ]
GEODE-5863: Ingoring testMultipleExecuteWithInitialResults
This test fails after increasing the Awaitility timeout. However, it
previously was not testing anything because it hit the (smaller)
awailitity timeout but ignored the timeout exception.
Ignoring this test until we actually rework this into a valid test.
Co-Authored-By "Ken Howe"
> CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion
> failures
>
>
> Key: GEODE-5863
> URL: https://issues.apache.org/jira/browse/GEODE-5863
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
>
> This test has assertions in an asynchronous thread. However, it never
> actually checks the results from that thread, it just asserts that the thread
> finishes. In practice, processCqs always throws an Awaitility exception,
> which is ignored and the test passes.
> This is the problematic code. ThreadUtils.join does not check the result of
> the async invocation:
> {code}
> ThreadUtils.join(processCqs, 60 * 1000);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656123#comment-16656123 ] ASF subversion and git services commented on GEODE-5424: Commit 1954e9220a5b890449916d6e5c38a61518eace00 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1954e92 ] GEODE-5424: Adding a spotless rule to enforce using GeodeAwaitility Any tests that use regular awaitility will now fail the spotless check, to avoid checking tests that don't pick up our default wait time. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656118#comment-16656118 ] ASF subversion and git services commented on GEODE-5424: Commit 8fa6ef6205938767d0106810daca1f91ee8bb3a8 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8fa6ef6 ] GEODE-5424: Replacing calls to waitForCriterion with Awaitility Replacing all of the calls to waitForCriterion with awaitility instead, to use a standard timeout. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656119#comment-16656119 ] ASF subversion and git services commented on GEODE-5424: Commit 1156e040c5cf5e761025937914a32373c2a90a8f in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1156e04 ] GEODE-5424: Fixing a test that was using awaitility as a sleep PersistentColocatedPartitionedRegionDUnitTest and QueryDataDUnitTest previously were using Awaitility as an overcomplicated way to make a thread sleep. We should eliminate these sleeps, but to avoid changing behavior with this PR, switching the Awaitility calls into regular sleeps. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656120#comment-16656120 ] ASF subversion and git services commented on GEODE-5424: Commit ff13a158020f9467a444ad4b4090c776bf463a71 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff13a15 ] GEODE-5424: Fix tests with races relying on a poll delay These tests all were only passing because awaitility waited 100 ms before testing anything. They may all be existing flaky tests. - ClusterDistributionManagerForAdminDUnitTest - if the assertion ever failed, it would fail the awaility with a formatting error - testLeadShutdownAndCoordFailure - Further clauses also needed to be in awailitility. - testConcurrentOperationsDunitTestOnBlockingQueue - recoversFromCloseDuringRegionOperation > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656117#comment-16656117 ] ASF subversion and git services commented on GEODE-5424: Commit 239c532f8338c9d8e9bb8062fab9fadd3376ec73 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=239c532 ] GEODE-5424: Changing all awaitility calls to use consistent timings We have a lot of Awaitility calls in our tests. Each test was picking its own timeout. That lead to some tests picking too small of a timeout and failing spuriously. With this change, all tests will use a new factory, GeodeAwaility.await(), rather than Awaitility.await(). This new factory sets a default timeout of 5 minutes. It also sets a sensible pollDelay and pollInterval. The custom timeouts used in all tests have been removed, in favor of this new factory, except for a couple of tests that had waits greater than 5 minutes. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)
[
https://issues.apache.org/jira/browse/GEODE-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5816:
Assignee: (was: Dan Smith)
> ClusterStartupRule fails to launch JMX manager (port already in use)
>
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill
>Priority: Major
> Labels: swat
>
> We see these related failures on a couple tests in
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs
> before the tests run, we think the problem lies outside the
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
> 4 failures (99.600% success
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
> | .testAddRmNewMemberWithReplicatedRegionsAndSubregions: 1 failures
> (99.900% success rate)
> | | Failed build 24 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
> | .testMultiplePartitionedRegions: 3 failures (99.700% success rate)
> | | Failed build 982 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
> | | Failed build 256 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC
> tid=0x20] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:68)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$22d9b8a8$1(ClusterStartupRule.java:206)
> 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)
>
[jira] [Assigned] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
[
https://issues.apache.org/jira/browse/GEODE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5863:
Assignee: Dan Smith
> CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion
> failures
>
>
> Key: GEODE-5863
> URL: https://issues.apache.org/jira/browse/GEODE-5863
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
>
> This test has assertions in an asynchronous thread. However, it never
> actually checks the results from that thread, it just asserts that the thread
> finishes. In practice, processCqs always throws an Awaitility exception,
> which is ignored and the test passes.
> This is the problematic code. ThreadUtils.join does not check the result of
> the async invocation:
> {code}
> ThreadUtils.join(processCqs, 60 * 1000);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656057#comment-16656057 ] ASF subversion and git services commented on GEODE-5424: Commit ff13a158020f9467a444ad4b4090c776bf463a71 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ff13a15 ] GEODE-5424: Fix tests with races relying on a poll delay These tests all were only passing because awaitility waited 100 ms before testing anything. They may all be existing flaky tests. - ClusterDistributionManagerForAdminDUnitTest - if the assertion ever failed, it would fail the awaility with a formatting error - testLeadShutdownAndCoordFailure - Further clauses also needed to be in awailitility. - testConcurrentOperationsDunitTestOnBlockingQueue - recoversFromCloseDuringRegionOperation > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
[
https://issues.apache.org/jira/browse/GEODE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656058#comment-16656058
]
ASF subversion and git services commented on GEODE-5863:
Commit 61014b2f20f4e57e59bb2ffe2e9968545ba0e37a in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=61014b2 ]
GEODE-5863: Ingoring testMultipleExecuteWithInitialResults
This test fails after increasing the Awaitility timeout. However, it
previously was not testing anything because it hit the (smaller)
awailitity timeout but ignored the timeout exception.
Ignoring this test until we actually rework this into a valid test.
Co-Authored-By "Ken Howe"
> CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion
> failures
>
>
> Key: GEODE-5863
> URL: https://issues.apache.org/jira/browse/GEODE-5863
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> This test has assertions in an asynchronous thread. However, it never
> actually checks the results from that thread, it just asserts that the thread
> finishes. In practice, processCqs always throws an Awaitility exception,
> which is ignored and the test passes.
> This is the problematic code. ThreadUtils.join does not check the result of
> the async invocation:
> {code}
> ThreadUtils.join(processCqs, 60 * 1000);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656060#comment-16656060 ] ASF subversion and git services commented on GEODE-5424: Commit 1954e9220a5b890449916d6e5c38a61518eace00 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1954e92 ] GEODE-5424: Adding a spotless rule to enforce using GeodeAwaitility Any tests that use regular awaitility will now fail the spotless check, to avoid checking tests that don't pick up our default wait time. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656054#comment-16656054 ] ASF subversion and git services commented on GEODE-5424: Commit 239c532f8338c9d8e9bb8062fab9fadd3376ec73 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=239c532 ] GEODE-5424: Changing all awaitility calls to use consistent timings We have a lot of Awaitility calls in our tests. Each test was picking its own timeout. That lead to some tests picking too small of a timeout and failing spuriously. With this change, all tests will use a new factory, GeodeAwaility.await(), rather than Awaitility.await(). This new factory sets a default timeout of 5 minutes. It also sets a sensible pollDelay and pollInterval. The custom timeouts used in all tests have been removed, in favor of this new factory, except for a couple of tests that had waits greater than 5 minutes. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656055#comment-16656055 ] ASF subversion and git services commented on GEODE-5424: Commit 8fa6ef6205938767d0106810daca1f91ee8bb3a8 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8fa6ef6 ] GEODE-5424: Replacing calls to waitForCriterion with Awaitility Replacing all of the calls to waitForCriterion with awaitility instead, to use a standard timeout. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656056#comment-16656056 ] ASF subversion and git services commented on GEODE-5424: Commit 1156e040c5cf5e761025937914a32373c2a90a8f in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1156e04 ] GEODE-5424: Fixing a test that was using awaitility as a sleep PersistentColocatedPartitionedRegionDUnitTest and QueryDataDUnitTest previously were using Awaitility as an overcomplicated way to make a thread sleep. We should eliminate these sleeps, but to avoid changing behavior with this PR, switching the Awaitility calls into regular sleeps. > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5424) Change all awaitility use to a standard timeout
[ https://issues.apache.org/jira/browse/GEODE-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-5424. -- Resolution: Fixed Fix Version/s: 1.8.0 > Change all awaitility use to a standard timeout > --- > > Key: GEODE-5424 > URL: https://issues.apache.org/jira/browse/GEODE-5424 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Lets change all use of Awaitility in geode to use a standard timeout of 5 > minutes. > We could do this by introducing a new static factory that wraps > Awaitility.await(), eg GeodeAwaitility.await() that sets the timeout to be 5 > minutes, and bulk change all of our use of Awaitility to GeodeAwaitility. > While we're at it, we might also want to change the default poll delay and > poll interval to something smaller if that will speed up our tests. > Relevant discussion thread on geode dev list: > https://geode.markmail.org/thread/cm2cngqupjsbipch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
[ https://issues.apache.org/jira/browse/GEODE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656059#comment-16656059 ] ASF subversion and git services commented on GEODE-5872: Commit 6d95888b9d13a6657536d0fa016f58d0ea45a80b in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d95888 ] GEODE-5872: Ignoring tests that are losing assertion failures Tests in PersistentColocatedPartitionedRegionDUnitTest had return statements that lost the assertion failure. These tests were previously passing because they got awailitity timeouts before the test timeout. Now the tests fail, but only because the timeouts are longer. Ignoring them for this PR. > Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions > -- > > Key: GEODE-5872 > URL: https://issues.apache.org/jira/browse/GEODE-5872 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > There are several tests in PersistentColocatedPartitionedRegionDUnitTest that > are have returns inside finally blocks. The effect of this is that the tests > are actually ignoring any assertion failures. > In practice, these tests fail with Awailility timeouts all the time. With my > changes for GEODE-5424, the tests now timeout because I increased the > awailitity timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5787) Support graceful bouncing DUnit VMs on windows
[ https://issues.apache.org/jira/browse/GEODE-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656027#comment-16656027 ] ASF subversion and git services commented on GEODE-5787: Commit 730e30092f689ea81a5419dd40c653c12cd16569 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from Sai Boorlagadda [ https://gitbox.apache.org/repos/asf?p=geode.git;h=730e300 ] Merge branch 'develop' into feature/GEODE-5787-dunit-internal > Support graceful bouncing DUnit VMs on windows > -- > > Key: GEODE-5787 > URL: https://issues.apache.org/jira/browse/GEODE-5787 > Project: Geode > Issue Type: New Feature > Components: tests >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Process.destroy is not graceful on windows and causes distributed system to > get into suspect processing and network partition when used in DUnit to > restart VMs. > There were existing JDK > [bugs|https://bugs.openjdk.java.net/browse/JDK-8056139] open requesting for > supporting graceful destroy for Windows. > Underlying native implementation on Linux can take advantage of SIGTERM vs > SIGKILL and JDK support process.destroy and process.destroyForcibly, where as > on Windows this differentiation is not possible so its unlikely that we will > see JDK support for graceful destroy. > A better approach would be to invoke 'System.exit( n )' using VM.invoke. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656024#comment-16656024
]
ASF subversion and git services commented on GEODE-5890:
Commit 810ade9d2e33af17cdb632f8e1c64d5e7f25ab98 in geode's branch
refs/heads/feature/GEODE-5787-dunit-internal from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=810ade9 ]
GEODE-5890: gateway events from the same distributed system should check
misorder (#2649)
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5852) Adding 1.7.0 to rolling / BC tests
[ https://issues.apache.org/jira/browse/GEODE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656025#comment-16656025 ] ASF subversion and git services commented on GEODE-5852: Commit de30e86685e6e9f705542aa948c7fa30d7edcb58 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~nabarunnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de30e86 ] GEODE-5852: Adding 1.7.0 to old version (#2596) * as 1.7.0 has been released, this version must be tested against the current snapshot * thus 1.7.0 has been added to the build.gradle file of the geode-old-version project. > Adding 1.7.0 to rolling / BC tests > -- > > Key: GEODE-5852 > URL: https://issues.apache.org/jira/browse/GEODE-5852 > Project: Geode > Issue Type: Bug >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > As Apache Geode 1.7.0 has been released we are adding it as an old version in > geode-old-versions project's build.gradle file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656022#comment-16656022
]
ASF subversion and git services commented on GEODE-5819:
Commit 646ff599b691e940b05bcbd8ce86ffb267ead7f3 in geode's branch
refs/heads/feature/GEODE-5787-dunit-internal from jinmeiliao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=646ff59 ]
GEODE-5819: update the keystore used in ssl test to make it jdk11 compatible.
(#2664)
> Handshake fails on Java11
> -
>
> Key: GEODE-5819
> URL: https://issues.apache.org/jira/browse/GEODE-5819
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuite|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuite]
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuiteLegacy|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuiteLegacy]
> {noformat}
> java.lang.RuntimeException: unexpected exception
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.validateConnection(RestAPIsWithSSLDUnitTest.java:512)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite(RestAPIsWithSSLDUnitTest.java:701)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Commented] (GEODE-5877) ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in MultithreadedTestCase failure
[
https://issues.apache.org/jira/browse/GEODE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656021#comment-16656021
]
ASF subversion and git services commented on GEODE-5877:
Commit cd3602b3e518547770eb958f36847cc24539c910 in geode's branch
refs/heads/feature/GEODE-5787-dunit-internal from [~demery]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd3602b ]
GEODE-5877: Make multithreaded test single-threaded
Rewrite ServerLauncherWaitOnServerTest to be single-threaded. Instead of
using a second thread to signal the termination conditions, we signal
the conditions by mocking collaborators.
Add tests for other conditions that cause waitOnServer() to exit.
Remove MultiThreadedTC library.
Co-Authored-By: Dan Smith
> ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in
> MultithreadedTestCase failure
> --
>
> Key: GEODE-5877
> URL: https://issues.apache.org/jira/browse/GEODE-5877
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed in a precheckin run:
> https://concourse.apachegeode-ci.info/builds/4982
> {noformat}
> java.lang.AssertionError: junit.framework.AssertionFailedError: expected:<0>
> but was:<1>
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.runTest(ServerLauncherWaitOnServerMultiThreadedTest.java:61)
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.waitOnServer(ServerLauncherWaitOnServerMultiThreadedTest.java:54)
> 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.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:106)
> 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
>
[jira] [Commented] (GEODE-5891) CreateRegionCommandIntegrationTest failed with jdk11
[ https://issues.apache.org/jira/browse/GEODE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656023#comment-16656023 ] ASF subversion and git services commented on GEODE-5891: Commit 8de7c3f3a13a304dad66699d6b74a7de57660d53 in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8de7c3f ] GEODE-5891: jdk 11 changed the error message when an object can not be cased to a class (#2644) > CreateRegionCommandIntegrationTest failed with jdk11 > > > Key: GEODE-5891 > URL: https://issues.apache.org/jira/browse/GEODE-5891 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest > > invalidCompressor FAILED > java.lang.AssertionError: > Expecting: > <"Member | Status > -- | > --- > server | ERROR: class java.lang.String cannot be cast to class > org.apache.geode.compression.Compressor (java.lang.String is in module > java.base of loader 'bootstrap'; org.apache.geode.compression.Compressor is > in unnamed module of loader 'app') > "> > to contain: > <"java.lang.String cannot be cast to > org.apache.geode.compression.Compressor"> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:85) > at > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest.invalidCompressor(CreateRegionCommandIntegrationTest.java:252) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656019#comment-16656019 ] ASF subversion and git services commented on GEODE-5864: Commit d19c8caa5f04c008d8366ca8c34f6268fd8652fe in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d19c8ca ] [GEODE-5864] Fix metrics pipeline resource paths value. (#2661) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 9h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656018#comment-16656018 ] ASF subversion and git services commented on GEODE-5864: Commit c365dd6d64f515992f62b82f03207877044fbc8e in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c365dd6 ] [GEODE-5864] More fixes, and make script executable. (#2660) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 9h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656020#comment-16656020 ] ASF subversion and git services commented on GEODE-5864: Commit dacf10f327a5ef4bdc34d4e287bbf2229938990f in geode's branch refs/heads/feature/GEODE-5787-dunit-internal from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dacf10f ] [GEODE-5864] push concourse-url down to metrics pipeline. (#2663) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 9h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-5901) add 1.7.0 to geode-old-versions/build.gradle
[ https://issues.apache.org/jira/browse/GEODE-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda closed GEODE-5901. -- > add 1.7.0 to geode-old-versions/build.gradle > > > Key: GEODE-5901 > URL: https://issues.apache.org/jira/browse/GEODE-5901 > Project: Geode > Issue Type: Bug >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5901) add 1.7.0 to geode-old-versions/build.gradle
[ https://issues.apache.org/jira/browse/GEODE-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda resolved GEODE-5901. Resolution: Duplicate > add 1.7.0 to geode-old-versions/build.gradle > > > Key: GEODE-5901 > URL: https://issues.apache.org/jira/browse/GEODE-5901 > Project: Geode > Issue Type: Bug >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5901) add 1.7.0 to geode-old-versions/build.gradle
[ https://issues.apache.org/jira/browse/GEODE-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda reassigned GEODE-5901: -- Assignee: Sai Boorlagadda > add 1.7.0 to geode-old-versions/build.gradle > > > Key: GEODE-5901 > URL: https://issues.apache.org/jira/browse/GEODE-5901 > Project: Geode > Issue Type: Bug >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5901) add 1.7.0 to geode-old-versions/build.gradle
Sai Boorlagadda created GEODE-5901: -- Summary: add 1.7.0 to geode-old-versions/build.gradle Key: GEODE-5901 URL: https://issues.apache.org/jira/browse/GEODE-5901 Project: Geode Issue Type: Bug Reporter: Sai Boorlagadda -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5900) Multiple failures from CqQueryOptimizedExecuteDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5900:
-
Labels: swat (was: )
> Multiple failures from CqQueryOptimizedExecuteDUnitTest
> ---
>
> Key: GEODE-5900
> URL: https://issues.apache.org/jira/browse/GEODE-5900
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> This test failed multiple times in our last mass flaky test run. It looks
> like maybe there are some systematic issues with either CQs or the way this
> test is working. It has a 20 second wait time (unit GEODE-5424 is merged),
> maybe that's not enough?
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest: 4
> failures (99.600% success rate)
> | .testForSupportedRegionAttributes: 1 failures (99.900% success rate)
> | | Failed build 723 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/723
> | .testCQEventsWithNotEqualsUndefined: 1 failures (99.900% success rate)
> | | Failed build 227 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/227
> | .testCQPrimaryLeaves: 2 failures (99.800% success rate)
> | | Failed build 641 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/641
> | | Failed build 351 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/351
> {noformat}
> Sample failures:
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest >
> testCQPrimaryLeaves FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.CqQueryDUnitTest$$Lambda$73/1828515910.run
> in VM 2 running on Host 12de275efacc with 4 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 2 ms: Did
> not receive expected number of calls to cqsDisconnected() null expected: 0
> received: 1
> {noformat}
> http://files.apachegeode-ci.info/builds/1.8.0-build.1/test-results/distributedTest/1537857570/
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest >
> testCQEventsWithNotEqualsUndefined FAILED
>
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.CqQueryDUnitTest$$Lambda$63/1228313463.run
> in VM 1 running on Host 91d9ecfa0d81 with 4 VMs
>
> Caused by:
> org.junit.ComparisonFailure: [Query Delete Event mismatch]
> expected:<[5]> but was:<[4]>
> {noformat}
> http://files.apachegeode-ci.info/builds/1.8.0-build.1/test-results/distributedTest/1537752577/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5900) Multiple failures from CqQueryOptimizedExecuteDUnitTest
Dan Smith created GEODE-5900:
Summary: Multiple failures from CqQueryOptimizedExecuteDUnitTest
Key: GEODE-5900
URL: https://issues.apache.org/jira/browse/GEODE-5900
Project: Geode
Issue Type: Improvement
Reporter: Dan Smith
This test failed multiple times in our last mass flaky test run. It looks like
maybe there are some systematic issues with either CQs or the way this test is
working. It has a 20 second wait time (unit GEODE-5424 is merged), maybe that's
not enough?
{noformat}
org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest: 4
failures (99.600% success rate)
| .testForSupportedRegionAttributes: 1 failures (99.900% success rate)
| | Failed build 723 at
https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/723
| .testCQEventsWithNotEqualsUndefined: 1 failures (99.900% success rate)
| | Failed build 227 at
https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/227
| .testCQPrimaryLeaves: 2 failures (99.800% success rate)
| | Failed build 641 at
https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/641
| | Failed build 351 at
https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/351
{noformat}
Sample failures:
{noformat}
org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest >
testCQPrimaryLeaves FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.cq.dunit.CqQueryDUnitTest$$Lambda$73/1828515910.run
in VM 2 running on Host 12de275efacc with 4 VMs
Caused by:
java.lang.AssertionError: Event never occurred after 2 ms: Did not
receive expected number of calls to cqsDisconnected() null expected: 0
received: 1
{noformat}
http://files.apachegeode-ci.info/builds/1.8.0-build.1/test-results/distributedTest/1537857570/
{noformat}
org.apache.geode.cache.query.cq.dunit.CqQueryOptimizedExecuteDUnitTest >
testCQEventsWithNotEqualsUndefined FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.cq.dunit.CqQueryDUnitTest$$Lambda$63/1228313463.run
in VM 1 running on Host 91d9ecfa0d81 with 4 VMs
Caused by:
org.junit.ComparisonFailure: [Query Delete Event mismatch]
expected:<[5]> but was:<[4]>
{noformat}
http://files.apachegeode-ci.info/builds/1.8.0-build.1/test-results/distributedTest/1537752577/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5886) Make extension module dependencies explicit.
[ https://issues.apache.org/jira/browse/GEODE-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5886: --- Assignee: Patrick Rhomberg > Make extension module dependencies explicit. > > > Key: GEODE-5886 > URL: https://issues.apache.org/jira/browse/GEODE-5886 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5899) Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and *-web-api
[ https://issues.apache.org/jira/browse/GEODE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5899: --- Assignee: Patrick Rhomberg > Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and > *-web-api > -- > > Key: GEODE-5899 > URL: https://issues.apache.org/jira/browse/GEODE-5899 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5885) Add geode-core exclusion from all geode-junit and geode-dunit dependencies
[ https://issues.apache.org/jira/browse/GEODE-5885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5885: --- Assignee: Patrick Rhomberg > Add geode-core exclusion from all geode-junit and geode-dunit dependencies > -- > > Key: GEODE-5885 > URL: https://issues.apache.org/jira/browse/GEODE-5885 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Failing to exclude geode-core causes the Nebula dependency linter to object > to what appear to be circular dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5899) Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and *-web-api
[ https://issues.apache.org/jira/browse/GEODE-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655962#comment-16655962 ] Patrick Rhomberg commented on GEODE-5899: - Pull request ready but dependent on GEODE-5885 / Pull Request #2640. > Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and > *-web-api > -- > > Key: GEODE-5899 > URL: https://issues.apache.org/jira/browse/GEODE-5899 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5899) Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and *-web-api
Patrick Rhomberg created GEODE-5899: --- Summary: Make dependencies explicit in geode-lucene, *-old-client-support, *-web, and *-web-api Key: GEODE-5899 URL: https://issues.apache.org/jira/browse/GEODE-5899 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5852) Adding 1.7.0 to rolling / BC tests
[ https://issues.apache.org/jira/browse/GEODE-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655942#comment-16655942 ] ASF subversion and git services commented on GEODE-5852: Commit de30e86685e6e9f705542aa948c7fa30d7edcb58 in geode's branch refs/heads/develop from [~nabarunnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de30e86 ] GEODE-5852: Adding 1.7.0 to old version (#2596) * as 1.7.0 has been released, this version must be tested against the current snapshot * thus 1.7.0 has been added to the build.gradle file of the geode-old-version project. > Adding 1.7.0 to rolling / BC tests > -- > > Key: GEODE-5852 > URL: https://issues.apache.org/jira/browse/GEODE-5852 > Project: Geode > Issue Type: Bug >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > As Apache Geode 1.7.0 has been released we are adding it as an old version in > geode-old-versions project's build.gradle file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)
[
https://issues.apache.org/jira/browse/GEODE-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5816:
Assignee: Dan Smith
> ClusterStartupRule fails to launch JMX manager (port already in use)
>
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
>
> We see these related failures on a couple tests in
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs
> before the tests run, we think the problem lies outside the
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
> 4 failures (99.600% success
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
> | .testAddRmNewMemberWithReplicatedRegionsAndSubregions: 1 failures
> (99.900% success rate)
> | | Failed build 24 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
> | .testMultiplePartitionedRegions: 3 failures (99.700% success rate)
> | | Failed build 982 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
> | | Failed build 256 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC
> tid=0x20] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:68)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$22d9b8a8$1(ClusterStartupRule.java:206)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Resolved] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou resolved GEODE-5890.
--
Resolution: Fixed
Fix Version/s: 1.8.0
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)
[
https://issues.apache.org/jira/browse/GEODE-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655896#comment-16655896
]
Dan Smith commented on GEODE-5816:
--
Correction to my previous comment - I think the port supplier is working, but
this particular test gets ports two different ways. The PortSupplier fixes
tests that use LocatorStarterRule.withJmxService().withHttpService(), but this
test uses withHttpService but gets the JMX port with the below code
{noformat}
private Properties locatorProperties() {
int jmxPort = AvailablePortHelper.getRandomAvailableTCPPort();
Properties props = new Properties();
props.setProperty(MCAST_PORT, "0");
props.setProperty(LOG_LEVEL, "fine");
props.setProperty(ConfigurationProperties.JMX_MANAGER_HOSTNAME_FOR_CLIENTS,
"localhost");
props.setProperty(ConfigurationProperties.JMX_MANAGER_PORT, "" + jmxPort);
return props;
}
{noformat}
> ClusterStartupRule fails to launch JMX manager (port already in use)
>
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill
>Priority: Major
> Labels: swat
>
> We see these related failures on a couple tests in
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs
> before the tests run, we think the problem lies outside the
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
> 4 failures (99.600% success
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
> | .testAddRmNewMemberWithReplicatedRegionsAndSubregions: 1 failures
> (99.900% success rate)
> | | Failed build 24 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
> | .testMultiplePartitionedRegions: 3 failures (99.700% success rate)
> | | Failed build 982 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
> | | Failed build 256 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC
> tid=0x20] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
>
[jira] [Commented] (GEODE-5890) gateway events from the same distributed system did not check misorder
[
https://issues.apache.org/jira/browse/GEODE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655895#comment-16655895
]
ASF subversion and git services commented on GEODE-5890:
Commit 810ade9d2e33af17cdb632f8e1c64d5e7f25ab98 in geode's branch
refs/heads/develop from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=810ade9 ]
GEODE-5890: gateway events from the same distributed system should check
misorder (#2649)
> gateway events from the same distributed system did not check misorder
> --
>
> Key: GEODE-5890
> URL: https://issues.apache.org/jira/browse/GEODE-5890
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> Host name: rs-GEM-2228-1638a2i3xlarge-hydra-client-28
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-862.11.6.el7.x86_64
> Java version: 1.8.0_181
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /usr/local/regr/jdk/jdk1.8.0_181/jre
> #
> Product
> Product-Name: Pivotal GemFire
> Product-Version: 9.6.0
> Native version: native code unavailable
> Build
> Build-Date: 2018-09-18 00:33:49 +
> Build-Id: root 9
> Build-Java-Version: 1.8.0_171
> Build-Platform: Linux 4.4.0-89-generic amd64
> Open
> Source-Date: 2018-09-18 00:29:00 +
> Source-Repository: support/9.6
> Source-Revision: b404fab8c4fe962dc8adab827034efdbc93ab861
> Closed
> GemFire-Source-Date: 2018-09-10 23:15:03 +
> GemFire-Source-Repository: support/9.6
> GemFire-Source-Revision: f5a2b5ec6e6144a0635c41d1605b4586dd8acc6a
> Running on: /10.32.111.152, 4 cpu(s), amd64 Linux
> 3.10.0-862.11.6.el7.x86_64
> #
> Test was run from versioning/newWan/wanVersioning.bt
> Test:
> versioning/newWan/parRegSerialSenderKeysPerWanHct.conf
> bridgeHostsPerSite=3
> bridgeThreadsPerVM=2
> bridgeVMsPerHost=1
> clientMem=256m
> edgeHostsPerSite=2
> edgeThreadsPerVM=5
> edgeVMsPerHost=1
> enableFailover=true
> locatorHostsPerSite=1
> locatorThreadsPerVM=2
> locatorVMsPerHost=1
> maxOps=2
> redundantCopies=1
> resultWaitSec=1200
> serverMem=256m
> wanSites=4
> Run with local.conf:
> hydra.Prms-randomSeed=1537256262399;
> hydra.Prms-randomSeed=1537256262399;
> hydra.GemFirePrms-logLevel = fine;
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1537256262399;
> *** Test failed with this error:
> CLIENT vm_17_thr_50_edge_3_2_host1_11693
> TASK[0] versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA
> ERROR util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> util.TestException: Snapshot written by edge_1_2(pid=11618). Expected
> /DefaultRegion to be size 24, but it is size 23
> The following 1 keys were missing from /DefaultRegion: [Object_10]
> at
> newWan.WANOperationsClient.verifyRegionContents(WANOperationsClient.java:1089)
> at
> versioning.newWan.WanConflictResolverTest.validateEntryOperationFromBBSnapshot(WanConflictResolverTest.java:364)
> at
> versioning.newWan.WanConflictResolverTest.doOpsAndValidateHA(WanConflictResolverTest.java:319)
> at
> versioning.newWan.WanConflictResolverTest.HydraTask_doOpsAndValidateHA(WanConflictResolverTest.java:111)
> at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.execute(MethExecutor.java:181)
> at hydra.MethExecutor.execute(MethExecutor.java:149)
> at hydra.TestTask.execute(TestTask.java:197)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5891) CreateRegionCommandIntegrationTest failed with jdk11
[ https://issues.apache.org/jira/browse/GEODE-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655881#comment-16655881 ] ASF subversion and git services commented on GEODE-5891: Commit 8de7c3f3a13a304dad66699d6b74a7de57660d53 in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8de7c3f ] GEODE-5891: jdk 11 changed the error message when an object can not be cased to a class (#2644) > CreateRegionCommandIntegrationTest failed with jdk11 > > > Key: GEODE-5891 > URL: https://issues.apache.org/jira/browse/GEODE-5891 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest > > invalidCompressor FAILED > java.lang.AssertionError: > Expecting: > <"Member | Status > -- | > --- > server | ERROR: class java.lang.String cannot be cast to class > org.apache.geode.compression.Compressor (java.lang.String is in module > java.base of loader 'bootstrap'; org.apache.geode.compression.Compressor is > in unnamed module of loader 'app') > "> > to contain: > <"java.lang.String cannot be cast to > org.apache.geode.compression.Compressor"> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:85) > at > org.apache.geode.management.internal.cli.commands.CreateRegionCommandIntegrationTest.invalidCompressor(CreateRegionCommandIntegrationTest.java:252) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655879#comment-16655879
]
ASF subversion and git services commented on GEODE-5819:
Commit 646ff599b691e940b05bcbd8ce86ffb267ead7f3 in geode's branch
refs/heads/develop from jinmeiliao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=646ff59 ]
GEODE-5819: update the keystore used in ssl test to make it jdk11 compatible.
(#2664)
> Handshake fails on Java11
> -
>
> Key: GEODE-5819
> URL: https://issues.apache.org/jira/browse/GEODE-5819
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuite|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuite]
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuiteLegacy|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuiteLegacy]
> {noformat}
> java.lang.RuntimeException: unexpected exception
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.validateConnection(RestAPIsWithSSLDUnitTest.java:512)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite(RestAPIsWithSSLDUnitTest.java:701)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-5898) Cache methods do not throw CacheClosedException after closed
[
https://issues.apache.org/jira/browse/GEODE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5898:
--
Labels: pull-request-available (was: )
> Cache methods do not throw CacheClosedException after closed
>
>
> Key: GEODE-5898
> URL: https://issues.apache.org/jira/browse/GEODE-5898
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
>
> Despite the claim in the API docs that all methods on {{Cache}} through
> {{CacheClosedException}} many of the methods do not. Same had in previous
> versions but through refactoring they were lost. No tests asserted this
> expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5898) Cache methods do not throw CacheClosedException after closed
Jacob S. Barrett created GEODE-5898:
---
Summary: Cache methods do not throw CacheClosedException after
closed
Key: GEODE-5898
URL: https://issues.apache.org/jira/browse/GEODE-5898
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Jacob S. Barrett
Despite the claim in the API docs that all methods on {{Cache}} through
{{CacheClosedException}} many of the methods do not. Same had in previous
versions but through refactoring they were lost. No tests asserted this
expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5898) Cache methods do not throw CacheClosedException after closed
[
https://issues.apache.org/jira/browse/GEODE-5898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett reassigned GEODE-5898:
---
Assignee: Jacob S. Barrett
> Cache methods do not throw CacheClosedException after closed
>
>
> Key: GEODE-5898
> URL: https://issues.apache.org/jira/browse/GEODE-5898
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Jacob S. Barrett
>Assignee: Jacob S. Barrett
>Priority: Major
>
> Despite the claim in the API docs that all methods on {{Cache}} through
> {{CacheClosedException}} many of the methods do not. Same had in previous
> versions but through refactoring they were lost. No tests asserted this
> expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)
[
https://issues.apache.org/jira/browse/GEODE-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655815#comment-16655815
]
Dan Smith commented on GEODE-5816:
--
Looking in the logs for one of these runs, it looks like it actually picked the
same port for the http service and the JMX port. That is bound to be a conflict:
{noformat}
[vm0] http-service-port=25305
[vm0] jmx-manager=true
[vm0] jmx-manager-hostname-for-clients=localhost
[vm0] jmx-manager-port=25305
{noformat}
These means the port supplier fix in GEODE-5622 is not actually working, since
this test looks like it failed after those changes. We are still giving out the
same port to two different services.
> ClusterStartupRule fails to launch JMX manager (port already in use)
>
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill
>Priority: Major
> Labels: swat
>
> We see these related failures on a couple tests in
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs
> before the tests run, we think the problem lies outside the
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
> 4 failures (99.600% success
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
> | .testAddRmNewMemberWithReplicatedRegionsAndSubregions: 1 failures
> (99.900% success rate)
> | | Failed build 24 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
> | .testMultiplePartitionedRegions: 3 failures (99.700% success rate)
> | | Failed build 982 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
> | | Failed build 256 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC
> tid=0x20] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
> at
>
[jira] [Updated] (GEODE-5819) Handshake fails on Java11
[
https://issues.apache.org/jira/browse/GEODE-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5819:
--
Labels: pull-request-available (was: )
> Handshake fails on Java11
> -
>
> Key: GEODE-5819
> URL: https://issues.apache.org/jira/browse/GEODE-5819
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuite|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuite]
> *
> [RestAPIsWithSSLDUnitTest|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html].
>
> [testSSLWithMultipleCipherSuiteLegacy|http://files.apachegeode-ci.info/builds/1.8.0-build.5/test-results/distributedTest/1538508591/classes/org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.html#testSSLWithMultipleCipherSuiteLegacy]
> {noformat}
> java.lang.RuntimeException: unexpected exception
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.validateConnection(RestAPIsWithSSLDUnitTest.java:512)
> at
> org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest.testSSLWithMultipleCipherSuite(RestAPIsWithSSLDUnitTest.java:701)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
>
[jira] [Updated] (GEODE-5897) create jndi-binding gfsh command does not report errors
[
https://issues.apache.org/jira/browse/GEODE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar updated GEODE-5897:
Description:
The command succeeds even if there was an error on the server. E.g.
{noformat}
gfsh>create jndi-binding --connection-url=lcoalsthag --name=ds2
--jdbc-driver-class="asdffii" --type=SIMPLE --username=foo
Password: *
Member | Status | Message
-- | -- |
---
serv1 | OK | Initiated jndi binding "ds2" on "serv1". See server logs to
verify.
Changes to configuration for group 'cluster' are persisted.
{noformat}
But the server has an error in the logs:
{noformat}
[error 2018/10/18 11:26:27.385 PDT serv1
tid=0x48] An Exception was caught while trying to load the driver. asdffii
java.lang.ClassNotFoundException: asdffii
at org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:130)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
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:949)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:803)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:745)
[error 2018/10/18 11:26:27.386 PDT serv1
tid=0x48] DataSourceFactory::getSimpleDataSource:Exception while creating
GemfireBasicDataSource.Exception String=An Exception was caught while trying to
load the driver. asdffii
java.sql.SQLException: An Exception was caught while trying to load the
driver. asdffii
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:137)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
{noformat}
was:
The command succeeds even if there was an error on the server. E.g.
{noformat}
gfsh>create jndi-binding --connection-url=lcoalsthag --name=ds1
--jdbc-driver-class="asdffii" --type=SIMPLE Member | Status | Message -- |
-- | ---
serv1 | OK | Initiated jndi binding "ds1" on "serv1". See server logs to
verify. Changes to configuration for group 'cluster' are persisted.
{noformat}
But the server has an error in the logs:
{noformat}
[error 2018/10/18 11:26:27.385 PDT serv1
tid=0x48] An Exception was caught while trying to load the driver. asdffii
java.lang.ClassNotFoundException: asdffii
at org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:130)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
[jira] [Updated] (GEODE-5897) create jndi-binding gfsh command does not report errors
[
https://issues.apache.org/jira/browse/GEODE-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar updated GEODE-5897:
Description:
The command succeeds even if there was an error on the server. E.g.
{noformat}
gfsh>create jndi-binding --connection-url=lcoalsthag --name=ds1
--jdbc-driver-class="asdffii" --type=SIMPLE Member | Status | Message -- |
-- | ---
serv1 | OK | Initiated jndi binding "ds1" on "serv1". See server logs to
verify. Changes to configuration for group 'cluster' are persisted.
{noformat}
But the server has an error in the logs:
{noformat}
[error 2018/10/18 11:26:27.385 PDT serv1
tid=0x48] An Exception was caught while trying to load the driver. asdffii
java.lang.ClassNotFoundException: asdffii
at org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:130)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
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:949)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:803)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:745)
[error 2018/10/18 11:26:27.386 PDT serv1
tid=0x48] DataSourceFactory::getSimpleDataSource:Exception while creating
GemfireBasicDataSource.Exception String=An Exception was caught while trying to
load the driver. asdffii
java.sql.SQLException: An Exception was caught while trying to load the
driver. asdffii
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:137)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
{noformat}
was:
The command succeeds even if there was an error on the server. E.g.
{{{
gfsh>create jndi-binding --connection-url=lcoalsthag --name=ds1
--jdbc-driver-class="asdffii" --type=SIMPLE
Member | Status | Message
-- | -- |
---
serv1 | OK | Initiated jndi binding "ds1" on "serv1". See server logs to verify.
Changes to configuration for group 'cluster' are persisted.
}}}
But the server has an error in the logs:
```
[error 2018/10/18 11:26:27.385 PDT serv1
tid=0x48] An Exception was caught while trying to load the driver. asdffii
java.lang.ClassNotFoundException: asdffii
at org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:130)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
[jira] [Created] (GEODE-5897) create jndi-binding gfsh command does not report errors
Swapnil Bawaskar created GEODE-5897:
---
Summary: create jndi-binding gfsh command does not report errors
Key: GEODE-5897
URL: https://issues.apache.org/jira/browse/GEODE-5897
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Swapnil Bawaskar
The command succeeds even if there was an error on the server. E.g.
{{{
gfsh>create jndi-binding --connection-url=lcoalsthag --name=ds1
--jdbc-driver-class="asdffii" --type=SIMPLE
Member | Status | Message
-- | -- |
---
serv1 | OK | Initiated jndi binding "ds1" on "serv1". See server logs to verify.
Changes to configuration for group 'cluster' are persisted.
}}}
But the server has an error in the logs:
```
[error 2018/10/18 11:26:27.385 PDT serv1
tid=0x48] An Exception was caught while trying to load the driver. asdffii
java.lang.ClassNotFoundException: asdffii
at org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:170)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:130)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
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:949)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.doFunctionExecutionThread(ClusterDistributionManager.java:803)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
at java.lang.Thread.run(Thread.java:745)
[error 2018/10/18 11:26:27.386 PDT serv1
tid=0x48] DataSourceFactory::getSimpleDataSource:Exception while creating
GemfireBasicDataSource.Exception String=An Exception was caught while trying to
load the driver. asdffii
java.sql.SQLException: An Exception was caught while trying to load the driver.
asdffii
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.loadDriver(GemFireBasicDataSource.java:137)
at
org.apache.geode.internal.datasource.GemFireBasicDataSource.(GemFireBasicDataSource.java:68)
at
org.apache.geode.internal.datasource.DataSourceFactory.getSimpleDataSource(DataSourceFactory.java:75)
at
org.apache.geode.internal.jndi.JNDIInvoker.mapDatasource(JNDIInvoker.java:340)
at
org.apache.geode.management.internal.cli.functions.CreateJndiBindingFunction.executeFunction(CreateJndiBindingFunction.java:39)
at org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:32)
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:432)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
```
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5681) PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed
[ https://issues.apache.org/jira/browse/GEODE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-5681. --- Resolution: Cannot Reproduce I'm marking this as resolved / closed so that if it re-occurs hopefully someone will be forced to update this ticket with new artifacts. > PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed > - > > Key: GEODE-5681 > URL: https://issues.apache.org/jira/browse/GEODE-5681 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.6.0 >Reporter: Mark Hanson >Assignee: Jens Deppe >Priority: Major > Labels: swat > Attachments: loginwithdeprecatedssloptions.log > > > Test failed in concourse integration test: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/355 > geode-assembly > java.lang.AssertionError: > Expecting: > <"https://localhost:29786/pulse/login.html?error=BAD_CREDS;> > to contain: > <"/pulse/clusterDetail.html"> > at > org.apache.geode.test.junit.rules.GeodeHttpClientRule.loginToPulseAndVerify(GeodeHttpClientRule.java:84) > at > org.apache.geode.tools.pulse.PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions(PulseSecurityWithSSLTest.java:126) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:37) > 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:106) > 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:117) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at >
[jira] [Updated] (GEODE-5681) PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed
[ https://issues.apache.org/jira/browse/GEODE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-5681: -- Affects Version/s: 1.6.0 > PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed > - > > Key: GEODE-5681 > URL: https://issues.apache.org/jira/browse/GEODE-5681 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.6.0 >Reporter: Mark Hanson >Assignee: Jens Deppe >Priority: Major > Labels: swat > Attachments: loginwithdeprecatedssloptions.log > > > Test failed in concourse integration test: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/355 > geode-assembly > java.lang.AssertionError: > Expecting: > <"https://localhost:29786/pulse/login.html?error=BAD_CREDS;> > to contain: > <"/pulse/clusterDetail.html"> > at > org.apache.geode.test.junit.rules.GeodeHttpClientRule.loginToPulseAndVerify(GeodeHttpClientRule.java:84) > at > org.apache.geode.tools.pulse.PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions(PulseSecurityWithSSLTest.java:126) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:37) > 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:106) > 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:117) > 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 >
[jira] [Updated] (GEODE-5681) PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed
[ https://issues.apache.org/jira/browse/GEODE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-5681: -- Component/s: pulse > PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed > - > > Key: GEODE-5681 > URL: https://issues.apache.org/jira/browse/GEODE-5681 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.6.0 >Reporter: Mark Hanson >Assignee: Jens Deppe >Priority: Major > Labels: swat > Attachments: loginwithdeprecatedssloptions.log > > > Test failed in concourse integration test: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/355 > geode-assembly > java.lang.AssertionError: > Expecting: > <"https://localhost:29786/pulse/login.html?error=BAD_CREDS;> > to contain: > <"/pulse/clusterDetail.html"> > at > org.apache.geode.test.junit.rules.GeodeHttpClientRule.loginToPulseAndVerify(GeodeHttpClientRule.java:84) > at > org.apache.geode.tools.pulse.PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions(PulseSecurityWithSSLTest.java:126) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:37) > 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:106) > 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:117) > 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 >
[jira] [Assigned] (GEODE-5701) CI Failure: StopServerWithSecurityAcceptanceTest
[
https://issues.apache.org/jira/browse/GEODE-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5701:
---
Assignee: Kenneth Howe
> CI Failure: StopServerWithSecurityAcceptanceTest
>
>
> Key: GEODE-5701
> URL: https://issues.apache.org/jira/browse/GEODE-5701
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
>
> Several tests in StopServerWithSecurityAcceptanceTest fail on CI:
> {code:java}
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsClusterReaderOverJmx FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsClusterReaderOverJmx(StopServerWithSecurityAcceptanceTest.java:87)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsDataReaderOverHttp FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsDataReaderOverHttp(StopServerWithSecurityAcceptanceTest.java:57)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsDataReaderOverJmx FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsDataReaderOverJmx(StopServerWithSecurityAcceptanceTest.java:72)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > canStopServerAsClusterAdminOverHttp FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
>
[jira] [Commented] (GEODE-5681) PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed
[ https://issues.apache.org/jira/browse/GEODE-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655672#comment-16655672 ] Jens Deppe commented on GEODE-5681: --- CI has been rebuilt and the logs are gone for this failure. If this re-occurs please update with new artifacts. > PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions failed > - > > Key: GEODE-5681 > URL: https://issues.apache.org/jira/browse/GEODE-5681 > Project: Geode > Issue Type: Bug >Reporter: Mark Hanson >Assignee: Jens Deppe >Priority: Major > Labels: swat > Attachments: loginwithdeprecatedssloptions.log > > > Test failed in concourse integration test: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/IntegrationTest/builds/355 > geode-assembly > java.lang.AssertionError: > Expecting: > <"https://localhost:29786/pulse/login.html?error=BAD_CREDS;> > to contain: > <"/pulse/clusterDetail.html"> > at > org.apache.geode.test.junit.rules.GeodeHttpClientRule.loginToPulseAndVerify(GeodeHttpClientRule.java:84) > at > org.apache.geode.tools.pulse.PulseSecurityWithSSLTest.loginWithDeprecatedSSLOptions(PulseSecurityWithSSLTest.java:126) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:48) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:37) > 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:106) > 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:117) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at
[jira] [Resolved] (GEODE-5877) ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in MultithreadedTestCase failure
[
https://issues.apache.org/jira/browse/GEODE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5877.
--
Resolution: Fixed
Fix Version/s: 1.8.0
> ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in
> MultithreadedTestCase failure
> --
>
> Key: GEODE-5877
> URL: https://issues.apache.org/jira/browse/GEODE-5877
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed in a precheckin run:
> https://concourse.apachegeode-ci.info/builds/4982
> {noformat}
> java.lang.AssertionError: junit.framework.AssertionFailedError: expected:<0>
> but was:<1>
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.runTest(ServerLauncherWaitOnServerMultiThreadedTest.java:61)
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.waitOnServer(ServerLauncherWaitOnServerMultiThreadedTest.java:54)
> 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.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:106)
> 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:117)
> 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
>
[jira] [Commented] (GEODE-5877) ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in MultithreadedTestCase failure
[
https://issues.apache.org/jira/browse/GEODE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655665#comment-16655665
]
ASF subversion and git services commented on GEODE-5877:
Commit cd3602b3e518547770eb958f36847cc24539c910 in geode's branch
refs/heads/develop from [~demery]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd3602b ]
GEODE-5877: Make multithreaded test single-threaded
Rewrite ServerLauncherWaitOnServerTest to be single-threaded. Instead of
using a second thread to signal the termination conditions, we signal
the conditions by mocking collaborators.
Add tests for other conditions that cause waitOnServer() to exit.
Remove MultiThreadedTC library.
Co-Authored-By: Dan Smith
> ServerLauncherWaitOnServerMultiThreadedTest fails due to bugs in
> MultithreadedTestCase failure
> --
>
> Key: GEODE-5877
> URL: https://issues.apache.org/jira/browse/GEODE-5877
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dale Emery
>Priority: Major
> Labels: pull-request-available, swat
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed in a precheckin run:
> https://concourse.apachegeode-ci.info/builds/4982
> {noformat}
> java.lang.AssertionError: junit.framework.AssertionFailedError: expected:<0>
> but was:<1>
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.runTest(ServerLauncherWaitOnServerMultiThreadedTest.java:61)
> at
> org.apache.geode.distributed.ServerLauncherWaitOnServerMultiThreadedTest.waitOnServer(ServerLauncherWaitOnServerMultiThreadedTest.java:54)
> 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.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:106)
> 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
>
[jira] [Assigned] (GEODE-5813) Serialization filter is rejecting class ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-5813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-5813:
---
Assignee: Ryan McMahon
> Serialization filter is rejecting class ConditionTimeoutException
> -
>
> Key: GEODE-5813
> URL: https://issues.apache.org/jira/browse/GEODE-5813
> Project: Geode
> Issue Type: Bug
>Reporter: Bill
>Assignee: Ryan McMahon
>Priority: Major
> Labels: swat
>
> In mass-test-run
> QueryMonitorDUnitTest. testQueryMonitorRegionWithEviction failed on four
> runs. Here's one:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/652
> Looks like the DUnit test has serialized a ConditionTimeoutException, which
> causes an exception on the server during deserialization.
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1130
> [fatal 2018/09/28 02:22:42.272 UTC
> tid=0x20] Serialization filter is rejecting class
> org.awaitility.core.ConditionTimeoutException
> java.lang.Exception:
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:225)
> at com.sun.proxy.$Proxy26.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1239)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1878)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:431)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2962)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2906)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2977)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:99)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:74)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:267)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:275)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processChunkedResponse(AbstractOp.java:345)
> at
> org.apache.geode.cache.client.internal.QueryOp$QueryOpImpl.processResponse(QueryOp.java:171)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:225)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:198)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:276)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:894)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:787)
> at
> org.apache.geode.cache.client.internal.QueryOp.execute(QueryOp.java:59)
> at
> org.apache.geode.cache.client.internal.ServerProxy.query(ServerProxy.java:69)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.executeOnServer(DefaultQuery.java:341)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:222)
> at
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:203)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.exuteQuery(QueryMonitorDUnitTest.java:360)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.lambda$testQueryMonitorRegionWithEviction$bb17a952$4(QueryMonitorDUnitTest.java:210)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Assigned] (GEODE-5760) CI failure: Expected exception Not found in QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
[
https://issues.apache.org/jira/browse/GEODE-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-5760:
---
Assignee: Ryan McMahon (was: Kenneth Howe)
> CI failure: Expected exception Not found in
> QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
> -
>
> Key: GEODE-5760
> URL: https://issues.apache.org/jira/browse/GEODE-5760
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Bill
>Assignee: Ryan McMahon
>Priority: Major
> Labels: swat
>
> In
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/415
> {code}
> > Task :geode-cq:distributedTest
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest >
> testQueryMonitorRegionWithIndex FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest$$Lambda$104/648688972.run
> in VM 4 running on Host 17a0abd8c00d with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:70)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex(QueryMonitorDUnitTest.java:239)
> Caused by:
> java.lang.AssertionError: Expected exception Not found. Expected
> exception with message:
> "Query execution taking more than the max execution time"
> Found
> Pool unexpected socket timed out on client connection=Pooled
> Connection to localhost:37885: Connection[localhost:37885]@176708196). Server
> unreachable: could not connect after 1 attempts
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.verifyException(QueryMonitorDUnitTest.java:410)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.exuteQuery(QueryMonitorDUnitTest.java:363)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.lambda$testQueryMonitorRegionWithIndex$bb17a952$3(QueryMonitorDUnitTest.java:239)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5803.
-
Resolution: Fixed
Fix Version/s: 1.8.0
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655638#comment-16655638 ] ASF subversion and git services commented on GEODE-5864: Commit dacf10f327a5ef4bdc34d4e287bbf2229938990f in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dacf10f ] [GEODE-5864] push concourse-url down to metrics pipeline. (#2663) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 9h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5884) Executing a function with non HA should return any available partial results
[ https://issues.apache.org/jira/browse/GEODE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5884: -- Labels: pull-request-available (was: ) > Executing a function with non HA should return any available partial results > > > Key: GEODE-5884 > URL: https://issues.apache.org/jira/browse/GEODE-5884 > Project: Geode > Issue Type: Bug > Components: functions >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > > When a function is executed without single hop, it is sent to a > "coordinating" node. This node then creates tasks that are executed on other > remote nodes and itself. If any of the remote nodes or the local node gets > an exception, it will accumulate the exception and any results it has > currently received. It then completes and sends those results back to the > client. > There is a flag to waitOnException. We should set this to true if the > function is non HA. This will have the coordinating node wait for all > results before sending back to the client. The work is going to get executed > on the remote nodes anyways, so why not wait for the results? > This will mirror a single-hop execution where a single node may fail. If it > does, the client still receives results from the other nodes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655618#comment-16655618 ] ASF subversion and git services commented on GEODE-5864: Commit d19c8caa5f04c008d8366ca8c34f6268fd8652fe in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d19c8ca ] [GEODE-5864] Fix metrics pipeline resource paths value. (#2661) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 8h 50m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5440) SUPERFLAKY PRColocatedEquiJoinDUnitTest.testRRPRLocalQueryingWithHetroIndexes
[
https://issues.apache.org/jira/browse/GEODE-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-5440.
Resolution: Fixed
> SUPERFLAKY PRColocatedEquiJoinDUnitTest.testRRPRLocalQueryingWithHetroIndexes
> -
>
> Key: GEODE-5440
> URL: https://issues.apache.org/jira/browse/GEODE-5440
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
> Attachments: Test results - Class
> org.apache.geode.cache.query.partitioned.PRColocatedEquiJoinDUnitTest.html
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Flaky test in CI distributedTest job.
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache.query.partitioned.PRColocatedEquiJoinDUnitTest >
> testRRPRLocalQueryingWithHetroIndexes FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.partitioned.PRQueryDUnitHelper$36.run in VM 0
> running on Host 2709b168a57a with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.partitioned.PRColocatedEquiJoinDUnitTest.testRRPRLocalQueryingWithHetroIndexes(PRColocatedEquiJoinDUnitTest.java:873)
> Caused by:
> java.lang.AssertionError: FAILED:SelectResults size is different in
> both the cases. Size1=292 Size2 = 400; failed query=r1.ID = r2.id
> {noformat}
> Artifacts at
> http://files.apachegeode-ci.info/builds/geode-pr-2126/test-artifacts/1531783070/distributedtestcore-geode-pr-2126.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5257) ComparisonFailure in ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
[
https://issues.apache.org/jira/browse/GEODE-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-5257.
Resolution: Fixed
> ComparisonFailure in
> ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened
> ---
>
> Key: GEODE-5257
> URL: https://issues.apache.org/jira/browse/GEODE-5257
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> [http://precheckin.gemfire.pivotal.io/teams/main/pipelines/dale-pr-1994/jobs/integrationTest/builds/1]
> The PR that invoked this precheckin changed a single line in the Spotless
> configuration. It is extremely unlikely that the failure is related to that
> change.
> {noformat}
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest >
> customEntryTimeToLiveCanBeShortened FAILED
> org.junit.ComparisonFailure: expected:<"quickExpire"> but was:
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.cache30.ShorteningExpirationTimeRegressionTest.customEntryTimeToLiveCanBeShortened(ShorteningExpirationTimeRegressionTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655608#comment-16655608 ] ASF subversion and git services commented on GEODE-5864: Commit c365dd6d64f515992f62b82f03207877044fbc8e in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c365dd6 ] [GEODE-5864] More fixes, and make script executable. (#2660) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 8.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655601#comment-16655601 ] ASF subversion and git services commented on GEODE-5864: Commit 91182d6301c2255a6a644c75520e168d60c539f9 in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=91182d6 ] [GEODE-5864] Fix up final changes to metrics. (#2659) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 8h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655594#comment-16655594 ] ASF subversion and git services commented on GEODE-5864: Commit 3788a9546bb7c7b3754030e800cb422626fac968 in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3788a95 ] [GEODE-5864] Fix script call. (#2658) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 7h 50m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655586#comment-16655586 ] ASF subversion and git services commented on GEODE-5864: Commit ca682a18c917b524ab71922e2ba99ed5f7073951 in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ca682a1 ] [GEODE-5864] Fix name of create yml job. (#2656) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 7.5h > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655579#comment-16655579 ] ASF subversion and git services commented on GEODE-5864: Commit 29efe6ecf2733288eed8c1374042deaa4807e44f in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=29efe6e ] [GEODE-5864] Remove old set-metrics-pipeline job. (#2655) Co-authored-by: Sean Goller Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 7h 10m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-5894:
Issue Type: Task (was: Bug)
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Task
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655578#comment-16655578
]
ASF subversion and git services commented on GEODE-5894:
Commit 48f6b8e8fbe49150d787ef74af2ae17933eebb7e in geode's branch
refs/heads/develop from [~gosullivan]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=48f6b8e ]
GEODE-5894: correct misspelling in dependency-versions.properties (#2648)
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5894) bouncycastle is misspelled as bounty-castle in dependency-versions.properties
[
https://issues.apache.org/jira/browse/GEODE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-5894.
-
Resolution: Fixed
> bouncycastle is misspelled as bounty-castle in dependency-versions.properties
> -
>
> Key: GEODE-5894
> URL: https://issues.apache.org/jira/browse/GEODE-5894
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Trivial
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> geode-junit/build.gradle
> 41: compile('org.bouncycastle:bcpkix-jdk15on:' +
> project.'bounty-castle.version')
> gradle/dependency-versions.properties
> 21:bounty-castle.version = 1.59
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5864) Streamline and parameterize concourse environment
[ https://issues.apache.org/jira/browse/GEODE-5864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655564#comment-16655564 ] ASF subversion and git services commented on GEODE-5864: Commit bbb30290a1c096631690b49d654c764af929ab2b in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbb3029 ] [GEODE-5864] align metrics pipeline with other pipeline deployments. (#2652) Co-authored-by: Robert Houghton Co-authored-by: Patrick Rhomberg > Streamline and parameterize concourse environment > - > > Key: GEODE-5864 > URL: https://issues.apache.org/jira/browse/GEODE-5864 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 6h 50m > Remaining Estimate: 0h > > In order to simplify stamping out multiple CI environments such as for > developer use, parameterize infrastructure-specific variables and remove > unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5803) Code Cleanup: remove pathological geode-core test source set assignment.
[
https://issues.apache.org/jira/browse/GEODE-5803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655472#comment-16655472
]
ASF subversion and git services commented on GEODE-5803:
Commit 84233c304cb21de43db0040f5d2ca96614fbdedf in geode's branch
refs/heads/develop from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=84233c3 ]
GEODE-5803: Add license header
> Code Cleanup: remove pathological geode-core test source set assignment.
>
>
> Key: GEODE-5803
> URL: https://issues.apache.org/jira/browse/GEODE-5803
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {noformat}
> // geode-core/build.gradle:217-223
> dependencies {
> // Integration Tests
> integrationTestCompile sourceSets.test.output
> // Distributed Tests
> distributedTestCompile sourceSets.integrationTest.output
> }
> {noformat}
> The above is a severe gradle anti-pattern. Source sets should be defined via
> our testing facets, and any dependences that {{integrationTestCompile}} or
> {{distributedTestCompile}} required should be explicitly stated.
> At a preliminary glance, this appears to have been done to avoid detangling
> the tight coupling of {{geode-core:test:org.apache.geode.test.process}},
> {{*.test.golden}}, and these classes consumption in other modules.
> A module should not consume another module's test output. These classes
> should be promoted to "main" classes within the {{geode-junit}} or
> {{geode-dunit}} structures, as appropriate.
> Some discussion on this exists in the previous pull request, #2549.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
[
https://issues.apache.org/jira/browse/GEODE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-5875.
-
Resolution: Fixed
> gfsh destroy jndi-binding command actually removes all data sources
> ---
>
> Key: GEODE-5875
> URL: https://issues.apache.org/jira/browse/GEODE-5875
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When executing gfsh command {{destroy jndi-binding}}, besides the targeted
> data source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
[
https://issues.apache.org/jira/browse/GEODE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-5875:
Priority: Minor (was: Major)
> gfsh destroy jndi-binding command actually removes all data sources
> ---
>
> Key: GEODE-5875
> URL: https://issues.apache.org/jira/browse/GEODE-5875
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When executing gfsh command {{destroy jndi-binding}}, besides the targeted
> data source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5896) Function sendResult can not finish correctly when client stop receive data
[ https://issues.apache.org/jira/browse/GEODE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655175#comment-16655175 ] Dong Yang edited comment on GEODE-5896 at 10/18/18 1:17 PM: Root cause Client side onRegion function invocation actually need 2 meta information ready before executing the user-define function. The first is static meta include colocateWith, bucketCount,partitionResolver etc. The second is dynamic meta that mapping the bucketId to ServerLocation. Client should send request to right server based on these meta info. But because GemFire is a dynamic cluster, sometime maybe the network issue, maybe node down or new node join in. Client-side meta can not catch up the change. At that time,the request send from client should go to the node A but unfortunately go to a node B, then the request been redirect from node B to node A. When function finish the logic and sending result using sendResult as stream, the data will firstly send from nod A to node B ,then from node B to client. If client program been killed or cancelled, node B will catch an exception: java.net.SocketException: Connection reset by peer: socket write error. Then the server to client channel will be closed. But node A can not get any exception because the channel between server is shared . Node A found nothing wrong, so it will continuously send data to node B till all data send out. Based on the data volume, it will cost minutes, hours or even days. During the transfer, client will send more request to server, maybe same thing happens, client been cancelled and resend again. Finally the server-side resources will be exhausted. At that time, the only way is restarting the cluster. was (Author: twosand): Root cause Client side onRegion function invocation actually need 2 meta information ready before executing the user-define function. The first is static meta include colocateWith, bucketCount,partitionResolver etc. The second is dynamic meta that mapping the bucketId to ServerLocation. Client should send request to right server based on these meta info. But because GemFire is a dynamic cluster, sometime maybe the network issue, maybe node down or new node join in. Client-side meta can not catch up the change. Then the request send from client should go to the node A but unfortunately go to a node B, then the request been redirect from node B to node A. When function finish the logic and sending result using sendResult as streaming style, the result data stream will firstly send from nod A to node B ,then from node B to client. If client program been killed or cancelled, node B will catch an exception: java.net.SocketException: Connection reset by peer: socket write error. Then the server to client channel will be closed. But node A can not get any exception because the channel between server is shared . Node A found nothing wrong, so it will continuously send data to node B till all data send out. Based on the data volume, it will cost minutes, hours or even days. If client program send a new request and killed again, server-side resource will be exhausted. At that time, the only way is restarting the cluster. > Function sendResult can not finish correctly when client stop receive data > -- > > Key: GEODE-5896 > URL: https://issues.apache.org/jira/browse/GEODE-5896 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Dong Yang >Priority: Major > > Scenario: > # TCP client-server mode > # on Region with filter invocation > # single-hop enabled at client-side > # lots of data transfer from server to client > # Using sendResult send data from server to client as streaming style > Incident: > Client program killed or exit normally. Server-side can not detect the > exception so still sending data to client. Resources occupied sometimes a > very long time and get more worse when client resent the request. As result, > the cluster looks like hang in and can not response any request include api > invocation, gfsh comand , etc. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5896) Function sendResult can not finish correctly when client stop receive data
[ https://issues.apache.org/jira/browse/GEODE-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655175#comment-16655175 ] Dong Yang commented on GEODE-5896: -- Root cause Client side onRegion function invocation actually need 2 meta information ready before executing the user-define function. The first is static meta include colocateWith, bucketCount,partitionResolver etc. The second is dynamic meta that mapping the bucketId to ServerLocation. Client should send request to right server based on these meta info. But because GemFire is a dynamic cluster, sometime maybe the network issue, maybe node down or new node join in. Client-side meta can not catch up the change. Then the request send from client should go to the node A but unfortunately go to a node B, then the request been redirect from node B to node A. When function finish the logic and sending result using sendResult as streaming style, the result data stream will firstly send from nod A to node B ,then from node B to client. If client program been killed or cancelled, node B will catch an exception: java.net.SocketException: Connection reset by peer: socket write error. Then the server to client channel will be closed. But node A can not get any exception because the channel between server is shared . Node A found nothing wrong, so it will continuously send data to node B till all data send out. Based on the data volume, it will cost minutes, hours or even days. If client program send a new request and killed again, server-side resource will be exhausted. At that time, the only way is restarting the cluster. > Function sendResult can not finish correctly when client stop receive data > -- > > Key: GEODE-5896 > URL: https://issues.apache.org/jira/browse/GEODE-5896 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Dong Yang >Priority: Major > > Scenario: > # TCP client-server mode > # on Region with filter invocation > # single-hop enabled at client-side > # lots of data transfer from server to client > # Using sendResult send data from server to client as streaming style > Incident: > Client program killed or exit normally. Server-side can not detect the > exception so still sending data to client. Resources occupied sometimes a > very long time and get more worse when client resent the request. As result, > the cluster looks like hang in and can not response any request include api > invocation, gfsh comand , etc. > > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5896) Function sendResult can not finish correctly when client stop receive data
Dong Yang created GEODE-5896: Summary: Function sendResult can not finish correctly when client stop receive data Key: GEODE-5896 URL: https://issues.apache.org/jira/browse/GEODE-5896 Project: Geode Issue Type: Bug Components: functions Reporter: Dong Yang Scenario: # TCP client-server mode # on Region with filter invocation # single-hop enabled at client-side # lots of data transfer from server to client # Using sendResult send data from server to client as streaming style Incident: Client program killed or exit normally. Server-side can not detect the exception so still sending data to client. Resources occupied sometimes a very long time and get more worse when client resent the request. As result, the cluster looks like hang in and can not response any request include api invocation, gfsh comand , etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
