[jira] [Updated] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10266: --- Labels: needsTriage pull-request-available (was: needsTriage) > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-10266: Assignee: Mario Ivanac > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10260. - Fix Version/s: 1.15.0 Resolution: Fixed > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529697#comment-17529697 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk11 #318|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/318] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1128/test-results/distributedTest/1651182833/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1128/test-artifacts/1651182833/distributedtestfiles-openjdk11-1.15.0-build.1128.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529684#comment-17529684
]
Geode Integration commented on GEODE-6903:
--
Seen on support/1.14 in [windows-core-integration-test-openjdk11
#51.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/windows-core-integration-test-openjdk11/builds/51.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0958/test-results/integrationTest/1651181915/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0958/test-artifacts/1651181915/windows-coreintegrationtestfiles-openjdk11-1.14.5-build.0958.tgz].
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.14.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529683#comment-17529683
]
ASF GitHub Bot commented on GEODE-10259:
pdxcodemonkey commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861365008
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -247,31 +243,26 @@ Serializable*
ClientProxyMembershipID::readEssentialData(DataInput& input) {
auto dsName = std::dynamic_pointer_cast(input.readObject());
- initHostAddressVector(hostAddress, length);
+ initHostAddressVector(hostAddress.data(), length);
- if (vmKind != ClientProxyMembershipID::LONER_DM_TYPE) {
+ if (vmKind != kVmKindLoaner) {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(), nullptr, vmViewId);
} else {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(),
uniqueTag->value().c_str(), vmViewId);
}
-
- delete[] hostAddress;
- readAdditionalData(input);
-
- return this;
}
void ClientProxyMembershipID::readAdditionalData(DataInput& input) {
// Skip unused UUID (16) and weight (0);
input.advanceCursor(17);
}
-void ClientProxyMembershipID::increaseSynchCounter() { ++synch_counter; }
+void ClientProxyMembershipID::increaseSynchCounter() { ++synchCounter; }
Review Comment:
Seriously - what the heck does this thing do?? It starts at 2, and
`increaseSyncCounter` is called by the ThinClientPoolDM ctor, so is there only
ever one of these(???). If so, it's yeah just always 3. It gets written into
both clientId and memberId, but I also have no idea what, if any, information
in those things is ever unpacked on the server side.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529675#comment-17529675 ] Donal Evans commented on GEODE-10266: - [~mivanac] This failure is in a test that was recently [added in this PR|https://github.com/apache/geode/pull/7517] for GEODE-10020. It seems like the test is flaky. Would it be possible to assign this ticket to you since you wrote the test? It looks like there were two failures of the test in the PR pre-checkin while you were working on addressing review comments too, so ideally the PR would not have been merged until that had been addressed. First PR failure: [https://concourse.apachegeode-ci.info/builds/48410232#L626524d8:560] Second PR failure: [https://concourse.apachegeode-ci.info/builds/48456881#L6265370b:560] It's not clear yet what the failure rate for this test is, but if it's failing often, the commit may need to be reverted. > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529672#comment-17529672
]
ASF subversion and git services commented on GEODE-10228:
-
Commit 5f1d358db0da813cc4df71906bf2977a87c0c7f4 in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5f1d358db0 ]
Bugfix/GEODE-10228 DurableClientTestCase.testDurableHAFailover is failing
(#7608)
- The test was failing because it didn't wait for the
HARegionQueue to clear before shutting down the durable
client for test. Thus when it came back up, there was
an extra message in the queue.
- Reverse the order of readyforevents and registerinterest
- adding a close for the control listener
- Starting the server is not synchronous adjusted test accordingly
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10266: --- Assignee: (was: Donal Evans) > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10266: --- Assignee: Donal Evans > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider edited comment on GEODE-9474 at 4/28/22 7:41 PM: -- For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. This open has been added in: GEODE-10263 was (Author: dschneider): For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9474. - Fix Version/s: 1.15.0 Resolution: Fixed > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > Fix For: 1.15.0 > > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-9476.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
> Fix For: 1.15.0
>
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522987#comment-17522987
]
Darrel Schneider edited comment on GEODE-9476 at 4/28/22 7:40 PM:
--
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
This was done for 1.15 see: GEODE-10263
was (Author: dschneider):
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9471. - Fix Version/s: 1.15.0 Resolution: Fixed > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > Fix For: 1.15.0 > > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524628#comment-17524628 ] Darrel Schneider edited comment on GEODE-9471 at 4/28/22 7:37 PM: -- For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. This open has been added see: GEODE-10263 was (Author: dschneider): For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529599#comment-17529599 ] ASF subversion and git services commented on GEODE-10260: - Commit 6d7f3530bb5548fc8dd6c118b96fcafbdba8edf2 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d7f3530bb ] GEODE-10260: refactor out Filter interface to use Predicate (#7627) > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529597#comment-17529597 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk11 #315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/315] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1125/test-results/distributedTest/1651091440/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1125/test-artifacts/1651091440/distributedtestfiles-openjdk11-1.15.0-build.1125.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529595#comment-17529595 ] ASF subversion and git services commented on GEODE-10260: - Commit f117a59548fe392725616bf9f354748e1ba785d9 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f117a59548 ] GEODE-10260: make sure message is added before they are processed. (#7628) > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10266: -- Labels: needsTriage (was: ) > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529591#comment-17529591 ] Geode Integration commented on GEODE-10266: --- Seen in [acceptance-test-openjdk8 #312|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/312] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz]. > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
Vince Ford created GEODE-10266: -- Summary: CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed Key: GEODE-10266 URL: https://issues.apache.org/jira/browse/GEODE-10266 Project: Geode Issue Type: Bug Affects Versions: 1.15.0 Reporter: Vince Ford F : acceptance-test-openjdk8 > Task :geode-assembly:acceptanceTest SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest that uses org.apache.geode.test.dunit.VM, org.apache.geode.test.dunit.VMjava.lang.String expected: 4 but was: 3 within 5 minutes. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) at org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) Caused by: java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask.get(FutureTask.java:205) at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) ... 5 more 185 tests completed, 1 failed, 4 skipped =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test report artifacts from this job are available at: [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529577#comment-17529577
]
ASF GitHub Bot commented on GEODE-10259:
pdxcodemonkey commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861192592
##
cppcache/src/ClientHealthStats.cpp:
##
@@ -14,62 +14,58 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
+
#include "ClientHealthStats.hpp"
-#include "CacheImpl.hpp"
+#include
+#include
+#include
namespace apache {
namespace geode {
namespace client {
void ClientHealthStats::toData(DataOutput& output) const {
- output.writeInt(static_cast(m_numGets));
- output.writeInt(static_cast(m_numPuts));
- output.writeInt(static_cast(m_numMisses));
- output.writeInt(static_cast(m_numCacheListenerCalls));
- output.writeInt(static_cast(m_numThread));
- output.writeInt(static_cast(m_cpus));
- output.writeInt(static_cast(m_processCpuTime));
- m_updateTime->toData(output);
+ output.writeInt(static_cast(gets_));
+ output.writeInt(static_cast(puts_));
+ output.writeInt(static_cast(misses_));
+ output.writeInt(static_cast(cacheListenerCallsCompleted_));
+ output.writeInt(static_cast(threads_));
+ output.writeInt(static_cast(cpus_));
+ output.writeInt(static_cast(processCpuTime_));
+ updateTime_->toData(output);
Review Comment:
Okay cool - just trying to make certain you could always read the file.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529575#comment-17529575
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861188302
##
cppcache/src/ClientProxyMembershipID.hpp:
##
@@ -51,26 +46,37 @@ class ClientProxyMembershipID : public
DSMemberForVersionStamp {
const std::chrono::seconds durableClientTimeOut =
std::chrono::seconds::zero());
- // This constructor is only for testing and should not be used for any
- // other purpose. See testEntriesMapForVersioning.cpp for more details
+ /**
+ * This constructor is only for testing and should not be used for any
+ * other purpose. See testEntriesMapForVersioning.cpp for more details
+ */
ClientProxyMembershipID(const uint8_t* hostAddr, uint32_t hostAddrLen,
uint32_t hostPort, const char* dsname,
const char* uniqueTag, uint32_t vmViewId);
- // ClientProxyMembershipID(const char *durableClientId = nullptr, const
- // uint32_t durableClntTimeOut = 0);
+
ClientProxyMembershipID();
+
~ClientProxyMembershipID() noexcept override;
+
static void increaseSynchCounter();
+
static std::shared_ptr createDeserializable() {
return std::make_shared();
}
- // Do an empty check on the returned value. Only use after handshake is done.
+
+ /**
+ * Do an empty check on the returned value. Only use after handshake is done.
+ */
Review Comment:
Ok, I am going to fix it. I didn't even look at the implementation
previously. You are right, it is just a getter.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529574#comment-17529574
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861186288
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -247,31 +243,26 @@ Serializable*
ClientProxyMembershipID::readEssentialData(DataInput& input) {
auto dsName = std::dynamic_pointer_cast(input.readObject());
- initHostAddressVector(hostAddress, length);
+ initHostAddressVector(hostAddress.data(), length);
- if (vmKind != ClientProxyMembershipID::LONER_DM_TYPE) {
+ if (vmKind != kVmKindLoaner) {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(), nullptr, vmViewId);
} else {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(),
uniqueTag->value().c_str(), vmViewId);
}
-
- delete[] hostAddress;
- readAdditionalData(input);
-
- return this;
}
void ClientProxyMembershipID::readAdditionalData(DataInput& input) {
// Skip unused UUID (16) and weight (0);
input.advanceCursor(17);
}
-void ClientProxyMembershipID::increaseSynchCounter() { ++synch_counter; }
+void ClientProxyMembershipID::increaseSynchCounter() { ++synchCounter; }
Review Comment:
You should take a look at that value. I am pretty sure that is always 3. Not
sure what the point is.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529571#comment-17529571
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861181244
##
cppcache/src/ClientProxyMembershipID.hpp:
##
@@ -51,26 +46,37 @@ class ClientProxyMembershipID : public
DSMemberForVersionStamp {
const std::chrono::seconds durableClientTimeOut =
std::chrono::seconds::zero());
- // This constructor is only for testing and should not be used for any
- // other purpose. See testEntriesMapForVersioning.cpp for more details
+ /**
+ * This constructor is only for testing and should not be used for any
+ * other purpose. See testEntriesMapForVersioning.cpp for more details
+ */
ClientProxyMembershipID(const uint8_t* hostAddr, uint32_t hostAddrLen,
uint32_t hostPort, const char* dsname,
const char* uniqueTag, uint32_t vmViewId);
- // ClientProxyMembershipID(const char *durableClientId = nullptr, const
- // uint32_t durableClntTimeOut = 0);
+
ClientProxyMembershipID();
+
~ClientProxyMembershipID() noexcept override;
+
static void increaseSynchCounter();
+
static std::shared_ptr createDeserializable() {
return std::make_shared();
}
- // Do an empty check on the returned value. Only use after handshake is done.
+
+ /**
+ * Do an empty check on the returned value. Only use after handshake is done.
+ */
Review Comment:
I didn't want to get that deep into refactoring this. I wanted to keep to
protocol. I just hate seeing documentation comments using the wrong comment
format. We could wack the whole comment. I will leave the refactoring of the
name and purpose up to someone else.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529569#comment-17529569
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861179105
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -247,31 +243,26 @@ Serializable*
ClientProxyMembershipID::readEssentialData(DataInput& input) {
auto dsName = std::dynamic_pointer_cast(input.readObject());
- initHostAddressVector(hostAddress, length);
+ initHostAddressVector(hostAddress.data(), length);
- if (vmKind != ClientProxyMembershipID::LONER_DM_TYPE) {
+ if (vmKind != kVmKindLoaner) {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(), nullptr, vmViewId);
} else {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(),
uniqueTag->value().c_str(), vmViewId);
}
-
- delete[] hostAddress;
- readAdditionalData(input);
-
- return this;
}
void ClientProxyMembershipID::readAdditionalData(DataInput& input) {
// Skip unused UUID (16) and weight (0);
input.advanceCursor(17);
}
-void ClientProxyMembershipID::increaseSynchCounter() { ++synch_counter; }
+void ClientProxyMembershipID::increaseSynchCounter() { ++synchCounter; }
Review Comment:
It bugs you too... I thought about it...
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529570#comment-17529570
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861179313
##
cppcache/src/ClientProxyMembershipID.hpp:
##
@@ -36,10 +35,6 @@ namespace apache {
namespace geode {
namespace client {
-using internal::DSFid;
-
-class ClientProxyMembershipID;
Review Comment:
I know, right!
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529568#comment-17529568
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861178697
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -185,31 +182,31 @@ void ClientProxyMembershipID::toData(DataOutput&) const {
void ClientProxyMembershipID::fromData(DataInput& input) {
// deserialization for PR FX HA
- auto length = input.readArrayLength();
- auto hostAddress = new uint8_t[length];
- input.readBytesOnly(hostAddress, length);
- auto hostPort = input.readInt32();
- auto hostname =
+ const auto length = input.readArrayLength();
+ auto hostAddress = std::vector(length);
+ input.readBytesOnly(hostAddress.data(), length);
+ const auto hostPort = input.readInt32();
+ const auto hostname =
std::dynamic_pointer_cast(input.readObject());
- auto splitbrain = input.read();
- auto dcport = input.readInt32();
- auto vPID = input.readInt32();
- auto vmKind = input.read();
- auto aStringArray = CacheableStringArray::create();
+ const auto splitbrain = input.read();
+ const auto dcport = input.readInt32();
+ const auto vPID = input.readInt32();
+ const auto vmKind = input.read();
+ const auto aStringArray = CacheableStringArray::create();
aStringArray->fromData(input);
- auto dsName = std::dynamic_pointer_cast(input.readObject());
- auto uniqueTag =
+ const auto dsName =
std::dynamic_pointer_cast(input.readObject());
- auto durableClientId =
+ const auto uniqueTag =
std::dynamic_pointer_cast(input.readObject());
- auto durableClientTimeOut = std::chrono::seconds(input.readInt32());
- int32_t vmViewId = 0;
+ const auto durableClientId =
+ std::dynamic_pointer_cast(input.readObject());
+ const auto durableClientTimeOut = std::chrono::seconds(input.readInt32());
readVersion(splitbrain, input);
- initHostAddressVector(hostAddress, length);
+ initHostAddressVector(hostAddress.data(), length);
- if (vmKind != ClientProxyMembershipID::LONER_DM_TYPE) {
-vmViewId = std::stoi(uniqueTag->value());
+ if (vmKind != kVmKindLoaner) {
+auto vmViewId = std::stoi(uniqueTag->value());
initObjectVars(hostname->value().c_str(), hostPort,
durableClientId->value().c_str(), durableClientTimeOut,
dcport, vPID, vmKind, splitbrain, dsName->value().c_str(),
Review Comment:
Oh god, there is a book you could write on poorly named symbols in here...
If I get bored while making other changes maybe I will address this one.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529567#comment-17529567
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861177743
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -31,19 +26,20 @@
#include "Version.hpp"
#include "util/Log.hpp"
-#define DCPORT 12334
-#define VMKIND 13
-#define ROLEARRLENGTH 0
+namespace {
+constexpr int32_t kVersionMask = 0x8;
+constexpr int8_t kVmKindLoaner = 13;
Review Comment:
LOL! Probably auto correct.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529566#comment-17529566
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861177155
##
cppcache/src/ClientHealthStats.cpp:
##
@@ -14,62 +14,58 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
+
#include "ClientHealthStats.hpp"
-#include "CacheImpl.hpp"
+#include
+#include
+#include
namespace apache {
namespace geode {
namespace client {
void ClientHealthStats::toData(DataOutput& output) const {
- output.writeInt(static_cast(m_numGets));
- output.writeInt(static_cast(m_numPuts));
- output.writeInt(static_cast(m_numMisses));
- output.writeInt(static_cast(m_numCacheListenerCalls));
- output.writeInt(static_cast(m_numThread));
- output.writeInt(static_cast(m_cpus));
- output.writeInt(static_cast(m_processCpuTime));
- m_updateTime->toData(output);
+ output.writeInt(static_cast(gets_));
+ output.writeInt(static_cast(puts_));
+ output.writeInt(static_cast(misses_));
+ output.writeInt(static_cast(cacheListenerCallsCompleted_));
+ output.writeInt(static_cast(threads_));
+ output.writeInt(static_cast(cpus_));
+ output.writeInt(static_cast(processCpuTime_));
+ updateTime_->toData(output);
Review Comment:
Not sure what you mean by "version of the stat file"? The field type is
recorded in the stat file so the size change has no real affect on the consumer
of the file. The field sizes change in the protocol some time ago when we
dropped support for `int` type stats.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529565#comment-17529565
]
ASF GitHub Bot commented on GEODE-10259:
pivotal-jbarrett commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861175845
##
cppcache/integration/test/PdxJsonTypeTest.cpp:
##
@@ -101,8 +101,7 @@ TEST(PdxJsonTypeTest, testGfshQueryJsonInstances) {
cache.createPdxInstanceFactory(gemfireJsonClassName)
.writeString("entryName", "java-domain-class-entry")
.create());
- ASSERT_THROW(execution.withArgs(query).execute("QueryFunction"),
- CacheServerException);
+ ASSERT_NO_THROW(execution.withArgs(query).execute("QueryFunction"));
Review Comment:
I don't know. The original author left no clue as to why and if that was
truly the wanted behavior. The test seems to test a few things in a single
test. The name of the test leaves little clue. I don't know why the original
was even throwing an exception here.
> Update geode-native library protocol to 1.14
>
>
> Key: GEODE-10259
> URL: https://issues.apache.org/jira/browse/GEODE-10259
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> The geode-native library still talks the Geode 1.0.0 protocol, update to at
> 1.14.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10259) Update geode-native library protocol to 1.14
[
https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529564#comment-17529564
]
ASF GitHub Bot commented on GEODE-10259:
pdxcodemonkey commented on code in PR #962:
URL: https://github.com/apache/geode-native/pull/962#discussion_r861014615
##
cppcache/integration/test/PdxJsonTypeTest.cpp:
##
@@ -101,8 +101,7 @@ TEST(PdxJsonTypeTest, testGfshQueryJsonInstances) {
cache.createPdxInstanceFactory(gemfireJsonClassName)
.writeString("entryName", "java-domain-class-entry")
.create());
- ASSERT_THROW(execution.withArgs(query).execute("QueryFunction"),
- CacheServerException);
+ ASSERT_NO_THROW(execution.withArgs(query).execute("QueryFunction"));
Review Comment:
Wait, wut? Why does this stop throwing?
##
cppcache/src/ClientHealthStats.cpp:
##
@@ -14,62 +14,58 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
+
#include "ClientHealthStats.hpp"
-#include "CacheImpl.hpp"
+#include
+#include
+#include
namespace apache {
namespace geode {
namespace client {
void ClientHealthStats::toData(DataOutput& output) const {
- output.writeInt(static_cast(m_numGets));
- output.writeInt(static_cast(m_numPuts));
- output.writeInt(static_cast(m_numMisses));
- output.writeInt(static_cast(m_numCacheListenerCalls));
- output.writeInt(static_cast(m_numThread));
- output.writeInt(static_cast(m_cpus));
- output.writeInt(static_cast(m_processCpuTime));
- m_updateTime->toData(output);
+ output.writeInt(static_cast(gets_));
+ output.writeInt(static_cast(puts_));
+ output.writeInt(static_cast(misses_));
+ output.writeInt(static_cast(cacheListenerCallsCompleted_));
+ output.writeInt(static_cast(threads_));
+ output.writeInt(static_cast(cpus_));
+ output.writeInt(static_cast(processCpuTime_));
+ updateTime_->toData(output);
Review Comment:
Did the size of the fields here change with the version of the
protocol/server? Or has this just been wrong forever in the native client? If
it changed, is there a way to determine which version of a stat file you have?
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -247,31 +243,26 @@ Serializable*
ClientProxyMembershipID::readEssentialData(DataInput& input) {
auto dsName = std::dynamic_pointer_cast(input.readObject());
- initHostAddressVector(hostAddress, length);
+ initHostAddressVector(hostAddress.data(), length);
- if (vmKind != ClientProxyMembershipID::LONER_DM_TYPE) {
+ if (vmKind != kVmKindLoaner) {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(), nullptr, vmViewId);
} else {
// initialize the object with the values read and some dummy values
-initObjectVars("", hostPort, "", std::chrono::seconds::zero(), DCPORT, 0,
+initObjectVars("", hostPort, "", std::chrono::seconds::zero(), kDcPort, 0,
vmKind, 0, dsName->value().c_str(),
uniqueTag->value().c_str(), vmViewId);
}
-
- delete[] hostAddress;
- readAdditionalData(input);
-
- return this;
}
void ClientProxyMembershipID::readAdditionalData(DataInput& input) {
// Skip unused UUID (16) and weight (0);
input.advanceCursor(17);
}
-void ClientProxyMembershipID::increaseSynchCounter() { ++synch_counter; }
+void ClientProxyMembershipID::increaseSynchCounter() { ++synchCounter; }
Review Comment:
Can we please lose the 'h'? 'synch' isn't a normal English abbreviation for
anything...
##
cppcache/src/ClientProxyMembershipID.cpp:
##
@@ -185,31 +182,31 @@ void ClientProxyMembershipID::toData(DataOutput&) const {
void ClientProxyMembershipID::fromData(DataInput& input) {
// deserialization for PR FX HA
- auto length = input.readArrayLength();
- auto hostAddress = new uint8_t[length];
- input.readBytesOnly(hostAddress, length);
- auto hostPort = input.readInt32();
- auto hostname =
+ const auto length = input.readArrayLength();
+ auto hostAddress = std::vector(length);
+ input.readBytesOnly(hostAddress.data(), length);
+ const auto hostPort = input.readInt32();
+ const auto hostname =
std::dynamic_pointer_cast(input.readObject());
- auto splitbrain = input.read();
- auto dcport = input.readInt32();
- auto vPID = input.readInt32();
- auto vmKind = input.read();
- auto aStringArray = CacheableStringArray::create();
+ const auto splitbrain = input.read();
+ const auto dcport = input.readInt32();
+ const auto vPID = input.readInt32();
+ const auto vmKind = input.read();
+ const auto aStringArray = CacheableStringArray::create();
[jira] [Updated] (GEODE-10259) Update geode-native library protocol to 1.14
[ https://issues.apache.org/jira/browse/GEODE-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10259: --- Labels: pull-request-available (was: ) > Update geode-native library protocol to 1.14 > > > Key: GEODE-10259 > URL: https://issues.apache.org/jira/browse/GEODE-10259 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > > The geode-native library still talks the Geode 1.0.0 protocol, update to at > 1.14. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10265:
--
Labels: (was: needsTriage)
> DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML
> cannot be run in parallel with itself.
>
>
> Key: GEODE-10265
> URL: https://issues.apache.org/jira/browse/GEODE-10265
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
>
> This test uses a hardcoded cache.xml with a server port inside that is
> hardcoded. Basically, the second test started in parallel will have a bind
> error because the port is already in use. We should consider generating the
> file rather than using a static one.
>
> Stress-new-test failure.
> [https://concourse.apachegeode-ci.info/builds/48751343]
>
> This issue was discovered as part of the stress-new-test of GEODE-10228's PR
> {noformat}
>
> name="client"
> subscription-enabled="true"
> load-conditioning-interval="6"
> read-timeout="3" retry-attempts="5" >
> The Problem > < The Problem
>
>
> id="testReadyForEventsNotCalledImplicitlyWithCacheXML_region"
> statistics-enabled="true" pool-name="client" refid="PROXY">
>
> org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil$ControlListener
>
>
> {noformat}
>
> {noformat}
> DurableClientSimpleDUnitTest >
> testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
> in VM 0 running on Host
> heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
> with 4 VMs
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 450
> [error 2022/04/28 00:39:54.901 UTC
> tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
> false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server
> = true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
> org.apache.geode.GemFireIOException: While starting cache server
> CacheServer on port=10188 client subscription config policy=entry client
> subscription config capacity=1000 client subscription config overflow
> directory=.
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types
[ https://issues.apache.org/jira/browse/GEODE-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10261: -- Labels: pull-request-available (was: needsTriage pull-request-available) > VMProvider.invokeAsync does not consistently use Generic types > -- > > Key: GEODE-10261 > URL: https://issues.apache.org/jira/browse/GEODE-10261 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.14.4 >Reporter: Joris Melchior >Assignee: Patrick Johnsn >Priority: Minor > Labels: pull-request-available > > In the VMProvider class there are several invokeAsync methods with various > signatures and in some cases they come with Generic type parameters and in > some cases they don't. > It's possible that some of this is influenced by the use of > SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little > deeper to find out to what degree we need to or can make changes here. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10228:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10255) PdxSerializable not working correctly for multiple versions of the same class
[ https://issues.apache.org/jira/browse/GEODE-10255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10255: -- Labels: (was: needsTriage) > PdxSerializable not working correctly for multiple versions of the same class > - > > Key: GEODE-10255 > URL: https://issues.apache.org/jira/browse/GEODE-10255 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > *GIVEN* a couple of PdxSerializable implementations for the same class, let's > say v1 and v2 > *WHEN* you GET a v1 entry of this PdxSerializable just after client startup > and after that perform a PUT of v2 entry. > *THEN* the PUT operation uses the PdxType from v1 instead of the right one, > leading to data corruption -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-10265:
Description:
This test uses a hardcoded cache.xml with a server port inside that is
hardcoded. Basically, the second test started in parallel will have a bind
error because the port is already in use. We should consider generating the
file rather than using a static one.
Stress-new-test failure.
[https://concourse.apachegeode-ci.info/builds/48751343]
This issue was discovered as part of the stress-new-test of GEODE-10228's PR
{noformat}
The Problem > < The Problem
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil$ControlListener
{noformat}
{noformat}
DurableClientSimpleDUnitTest >
testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
Failures (2 failures)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
in VM 0 running on Host
heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
with 4 VMs
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 450
[error 2022/04/28 00:39:54.901 UTC
tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server =
true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
org.apache.geode.GemFireIOException: While starting cache server
CacheServer on port=10188 client subscription config policy=entry client
subscription config capacity=1000 client subscription config overflow
directory=.
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-10265:
Description:
This test uses a hardcoded cache.xml with a server port inside that is
hardcoded. Bascially, the second test started in parallel will have a bind
error because the port is already in use. We should consider generating the
file rather than using a static one.
Stress-new-test failure.
[https://concourse.apachegeode-ci.info/builds/48751343]
This issue was discovered as part of the stress-new-test of GEODE-10228's PR
{noformat}
The Problem > < The Problem
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil$ControlListener
{noformat}
{noformat}
DurableClientSimpleDUnitTest >
testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
Failures (2 failures)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
in VM 0 running on Host
heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
with 4 VMs
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 450
[error 2022/04/28 00:39:54.901 UTC
tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server =
true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
org.apache.geode.GemFireIOException: While starting cache server
CacheServer on port=10188 client subscription config policy=entry client
subscription config capacity=1000 client subscription config overflow
directory=.
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10265:
--
Labels: needsTriage (was: )
> DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML
> cannot be run in parallel with itself.
>
>
> Key: GEODE-10265
> URL: https://issues.apache.org/jira/browse/GEODE-10265
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> This test uses a hardcoded cache.xml with a server port inside that is
> hardcoded. Bascially the second test started in parallel will have a bind
> error because the port is already in use.
>
> Stress-new-test failure.
> https://concourse.apachegeode-ci.info/builds/48751343
>
> {noformat}
> DurableClientSimpleDUnitTest >
> testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
> in VM 0 running on Host
> heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
> with 4 VMs
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 450
> [error 2022/04/28 00:39:54.901 UTC
> tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
> false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server
> = true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
> org.apache.geode.GemFireIOException: While starting cache server
> CacheServer on port=10188 client subscription config policy=entry client
> subscription config capacity=1000 client subscription config overflow
> directory=.
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
>
[jira] [Updated] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
[
https://issues.apache.org/jira/browse/GEODE-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-10265:
Description:
This test uses a hardcoded cache.xml with a server port inside that is
hardcoded. Bascially the second test started in parallel will have a bind error
because the port is already in use.
Stress-new-test failure.
[https://concourse.apachegeode-ci.info/builds/48751343]
This issue was discovered as part of the stress-new-test of GEODE-10228's PR
{noformat}
DurableClientSimpleDUnitTest >
testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
Failures (2 failures)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
in VM 0 running on Host
heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
with 4 VMs
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 450
[error 2022/04/28 00:39:54.901 UTC
tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server =
true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
org.apache.geode.GemFireIOException: While starting cache server
CacheServer on port=10188 client subscription config policy=entry client
subscription config capacity=1000 client subscription config overflow
directory=.
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
[jira] [Created] (GEODE-10265) DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML cannot be run in parallel with itself.
Mark Hanson created GEODE-10265:
---
Summary:
DurableClientSimpleDUnitTest.testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML
cannot be run in parallel with itself.
Key: GEODE-10265
URL: https://issues.apache.org/jira/browse/GEODE-10265
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
This test uses a hardcoded cache.xml with a server port inside that is
hardcoded. Bascially the second test started in parallel will have a bind error
because the port is already in use.
Stress-new-test failure.
https://concourse.apachegeode-ci.info/builds/48751343
{noformat}
DurableClientSimpleDUnitTest >
testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML FAILED
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
Failures (2 failures)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest$$Lambda$364/438711076.call
in VM 0 running on Host
heavy-lifter-f7bd4fb4-95bb-5e71-b25c-83f8d8a79c56.c.apachegeode-ci.internal
with 4 VMs
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 450
[error 2022/04/28 00:39:54.901 UTC
tid=32] Cache initialization for GemFireCache[id = 1097663966; isClosing =
false; isShutDownAll = false; created = Thu Apr 28 00:37:54 UTC 2022; server =
true; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
org.apache.geode.GemFireIOException: While starting cache server
CacheServer on port=10188 client subscription config policy=entry client
subscription config capacity=1000 client subscription config overflow
directory=.
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:801)
at
org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:600)
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4202)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1620)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1445)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerTestUtil.createCacheServerFromXmlN(CacheServerTestUtil.java:253)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientSimpleDUnitTest.lambda$testReadyForEventsNotCalledImplicitlyForRegisterInterestWithCacheXML$515fd116$1(DurableClientSimpleDUnitTest.java:584)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529520#comment-17529520
]
Mark Hanson commented on GEODE-10228:
-
Tracked down a new issue found during stress-new-test of PR for GEODE-10228.
The basic problem is this test uses a hard coded port in the cache.xml for the
test. That means that the test cannot be run in parallel with itself, which is
what stress-new-test was doing. If we want to fix this test, (I suggest it
should be a low priority). We should not use a static cache.xml and shift to a
dynamically generated cache.xml. I am submitting a new bug for that particular
issue and merging the PR as the test in question is not new.
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10264) Geode user guide: remove the "Connect to the server from your application" section
[ https://issues.apache.org/jira/browse/GEODE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10264: Labels: (was: needsTriage) > Geode user guide: remove the "Connect to the server from your application" > section > -- > > Key: GEODE-10264 > URL: https://issues.apache.org/jira/browse/GEODE-10264 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > > Community member John Martin reported: > We need to remove the "Connect to the server from your application" section > from this page please: > https://geode.apache.org/docs/guide/114/getting_started/intro_to_clients.html > it is not accurate, and was a section I thought I had deleted before > submitting, but apparently I had not. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10263. -- Fix Version/s: 1.15.0 Resolution: Fixed > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529515#comment-17529515 ] ASF subversion and git services commented on GEODE-10263: - Commit 3f14431eaee4e385590fa403c0f0e63e11b43965 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f14431eae ] GEODE-10263: add opens required by geode features (#7632) added opens required by geode features and added javadoc comments that link to the class in geode that requires an open or export > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
