[jira] [Updated] (GEODE-9730) improve release scripts
[ https://issues.apache.org/jira/browse/GEODE-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9730: -- Labels: pull-request-available (was: ) > improve release scripts > --- > > Key: GEODE-9730 > URL: https://issues.apache.org/jira/browse/GEODE-9730 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > * add fan-in job to rc pipeline > * any other improvements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9730) improve release scripts
[ https://issues.apache.org/jira/browse/GEODE-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-9730: --- Assignee: Owen Nichols > improve release scripts > --- > > Key: GEODE-9730 > URL: https://issues.apache.org/jira/browse/GEODE-9730 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > * add fan-in job to rc pipeline > * any other improvements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9730) improve release scripts
Owen Nichols created GEODE-9730: --- Summary: improve release scripts Key: GEODE-9730 URL: https://issues.apache.org/jira/browse/GEODE-9730 Project: Geode Issue Type: Improvement Components: release Reporter: Owen Nichols * add fan-in job to rc pipeline * any other improvements -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428001#comment-17428001 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell commented on pull request #881: URL: https://github.com/apache/geode-native/pull/881#issuecomment-941909201 Rebased against develop to pickup fix for .../integration/test/FunctionExecutionTest.cpp -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-9702: --- Assignee: Robert Houghton > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9702. - Fix Version/s: 1.15.0 Resolution: Fixed > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
[ https://issues.apache.org/jira/browse/GEODE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427985#comment-17427985 ] ASF subversion and git services commented on GEODE-9705: Commit 07eb304921a94a922f1764bef537293cd5aca465 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07eb304 ] GEODE-9705: When create PR failed with DistributedSystemDisconnectedE… (#6964) > When create PR failed with DistributedSystemDisconnectedException, should use > it as cause of PartitionedRegionException > --- > > Key: GEODE-9705 > URL: https://issues.apache.org/jira/browse/GEODE-9705 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When PR failed with register itself, it will throw > DistributedSystemDisconnectedException in cleanupFailedInitialization(). > LockServiceDestroyedException should be the cause of > DistributedSystemDisconnectedException. > Currently, we throw PartitionedRegionException directly using > LockServiceDestroyedException, which is not expected. > The fix is to throw PartitionedRegionException using > DistributedSystemDisconnectedException (or any other RuntimeException) as > cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
[ https://issues.apache.org/jira/browse/GEODE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9705. -- Fix Version/s: 1.15.0 Resolution: Fixed > When create PR failed with DistributedSystemDisconnectedException, should use > it as cause of PartitionedRegionException > --- > > Key: GEODE-9705 > URL: https://issues.apache.org/jira/browse/GEODE-9705 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When PR failed with register itself, it will throw > DistributedSystemDisconnectedException in cleanupFailedInitialization(). > LockServiceDestroyedException should be the cause of > DistributedSystemDisconnectedException. > Currently, we throw PartitionedRegionException directly using > LockServiceDestroyedException, which is not expected. > The fix is to throw PartitionedRegionException using > DistributedSystemDisconnectedException (or any other RuntimeException) as > cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9674) Re-auth seems to cause durable clients lose some events when server force the client to disconnect
[ https://issues.apache.org/jira/browse/GEODE-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9674. Fix Version/s: 1.15.0 Resolution: Fixed > Re-auth seems to cause durable clients lose some events when server force the > client to disconnect > -- > > Key: GEODE-9674 > URL: https://issues.apache.org/jira/browse/GEODE-9674 > Project: Geode > Issue Type: Sub-task > Components: core >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > We have several intermittent test failures related to durable clients losing > data afternserver force the client to disconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
Eric Shu created GEODE-9729: --- Summary: CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED Key: GEODE-9729 URL: https://issues.apache.org/jira/browse/GEODE-9729 Project: Geode Issue Type: Bug Components: client/server Reporter: Eric Shu org.apache.geode.cache.client.AllConnectionsInUseException at org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) at org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) at org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) at org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) at org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) at org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) at org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) at org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) at java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
[ https://issues.apache.org/jira/browse/GEODE-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427971#comment-17427971 ] Geode Integration commented on GEODE-9729: -- Seen in [distributed-test-openjdk11 #267|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/267] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0569/test-results/distributedTest/1634075124/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0569/test-artifacts/1634075124/distributedtestfiles-openjdk11-1.15.0-build.0569.tgz]. > CI Failure: > PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED > - > > Key: GEODE-9729 > URL: https://issues.apache.org/jira/browse/GEODE-9729 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.client.AllConnectionsInUseException > at > org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) > at > org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) > at > org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) > at > org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) > at java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
[ https://issues.apache.org/jira/browse/GEODE-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9729: - Labels: needsTriage (was: ) > CI Failure: > PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED > - > > Key: GEODE-9729 > URL: https://issues.apache.org/jira/browse/GEODE-9729 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.client.AllConnectionsInUseException > at > org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) > at > org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) > at > org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) > at > org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) > at java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9581:
Comment: was deleted
(was: It's reproduced in
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899468
revision f41a1c56dbca3b4bfab159be217201aefd09be81
)
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9581:
-
Labels: needsTriage pull-request-available (was: pull-request-available)
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9639) Make native client compatible with C++20
[ https://issues.apache.org/jira/browse/GEODE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427953#comment-17427953 ] ASF GitHub Bot commented on GEODE-9639: --- pivotal-jbarrett commented on pull request #874: URL: https://github.com/apache/geode-native/pull/874#issuecomment-941736026 > * std::not1 (TcrMessage.cpp) Replace that whole `std::string::erase` statement with [`boost::algorithm::trim_left`](https://www.boost.org/doc/libs/1_77_0/doc/html/boost/algorithm/trim_left.html). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Make native client compatible with C++20 > > > Key: GEODE-9639 > URL: https://issues.apache.org/jira/browse/GEODE-9639 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Labels: pull-request-available > > There are standard library components that were removed in C++20, making our > library incompatible. Luckily, our use of deleted components are minimal and > replaceable without breaking API backward compatibility, but it will disrupt > ABI compatibility. > > The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, > including examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9722) Remove the SHUTDOWN redis command
[ https://issues.apache.org/jira/browse/GEODE-9722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9722: - Labels: release-blocker (was: ) > Remove the SHUTDOWN redis command > - > > Key: GEODE-9722 > URL: https://issues.apache.org/jira/browse/GEODE-9722 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > Labels: release-blocker > > This redis command is one of the unsupported operations, which can only be > enabled with a system property. Still, we don't want anyone to use this to > shutdown a gemfire server and we never intend to add support for it, so we > should just delete it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9728) Support COMMAND INFO
Wayne created GEODE-9728: Summary: Support COMMAND INFO Key: GEODE-9728 URL: https://issues.apache.org/jira/browse/GEODE-9728 Project: Geode Issue Type: New Feature Components: redis Reporter: Wayne Provide support for the [COMMAND INFO|https://redis.io/commands/command-info] command. +Acceptance Criteria+ The command has been implemented per specification along with appropriate automated tests. The command has been added to the AbstractHitsMissesIntegrationTest. The command has been tested using the redis-cli tool and verified against native redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9727: - Labels: (was: needsTriage) > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Priority: Major > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
Wayne created GEODE-9727: Summary: Redis Command COMMAND Should Throw Error With Invalid Arguments Key: GEODE-9727 URL: https://issues.apache.org/jira/browse/GEODE-9727 Project: Geode Issue Type: Bug Components: redis Reporter: Wayne The Redis command COMMAND should throw an error when provided with an illegal argument. Native Redis behaves as follows: COMMAND foo (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try COMMAND HELP. Our existing COMMANDimplementation does not provide an error messages for the extra argument and just executes the COMMAND normally as if no additional arguments were provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9727: - Labels: needsTriage (was: ) > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Priority: Major > Labels: needsTriage > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
[
https://issues.apache.org/jira/browse/GEODE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427949#comment-17427949
]
Dale Emery edited comment on GEODE-9714 at 10/12/21, 10:45 PM:
---
Note that geode-core and geode-cq both have tests with the same fully qualified
name
({{org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest}}).
See GEODE-9263.
was (Author: demery):
Note that geode-core and geode-cq both have tests with the same fully qualified
name ({{
{{org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest}})}}.
See GEODE-9263.
> CI: QueryConfigurationServiceConstraintsDistributedTest failed with
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> ---
>
> Key: GEODE-9714
> URL: https://issues.apache.org/jira/browse/GEODE-9714
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
> {code:java}
> QueryConfigurationServiceConstraintsDistributedTest > [10]
> indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
> FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 357
> [fatal 2021/10/09 19:11:41.270 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.StoppedSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
> at
> org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at
> org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
>
[jira] [Commented] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
[
https://issues.apache.org/jira/browse/GEODE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427949#comment-17427949
]
Dale Emery commented on GEODE-9714:
---
Note that geode-core and geode-cq both have tests with the same fully qualified
name ({{
{{org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest}})}}.
See GEODE-9263.
> CI: QueryConfigurationServiceConstraintsDistributedTest failed with
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> ---
>
> Key: GEODE-9714
> URL: https://issues.apache.org/jira/browse/GEODE-9714
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
> {code:java}
> QueryConfigurationServiceConstraintsDistributedTest > [10]
> indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
> FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 357
> [fatal 2021/10/09 19:11:41.270 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.StoppedSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
> at
> org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at
> org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
> at
> org.apache.geode.internal.cache.LocalRegion.serverDestroy(LocalRegion.java:3095)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforeDestroy(LocalRegion.java:2972)
> at
>
[jira] [Updated] (GEODE-9700) ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs
[ https://issues.apache.org/jira/browse/GEODE-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9700: - Labels: release-blocker (was: needsTriage) > ZUNIONSTORE and ZINTERSTORE need to work with regular sets as inputs > > > Key: GEODE-9700 > URL: https://issues.apache.org/jira/browse/GEODE-9700 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Priority: Major > Labels: release-blocker > > Some of the Redis TCL tests fail when running against Geode due to > ZUNIONSTORE and ZINTERSTORE taking regular sets (as opposed to sorted sets) > as input. Geode returns the error "WRONGTYPE Operation against a key holding > the wrong kind of value" when native Redis succeeds. > The tests include: > * ZUNIONSTORE with a regular set and weights > * ZINTERSTORE with a regular set and weights > * ZINTERSTORE regression with two sets, intset+hashtable > * ZINTERSTORE #516 regression, mixed sets and ziplist zsets > Enable these tests as part of this fix. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9699) ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
[
https://issues.apache.org/jira/browse/GEODE-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wayne updated GEODE-9699:
-
Labels: release-blocker (was: needsTriage)
> ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
>
>
> Key: GEODE-9699
> URL: https://issues.apache.org/jira/browse/GEODE-9699
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Eric Zoerner
>Priority: Major
> Labels: release-blocker
>
> The following redis TCL test fails when running against Geode for Redis:
> {code}
> # Geode fails with: Expected '1' to be equal to '0'
> test "ZUNIONSTORE against non-existing key doesn't set destination -
> $encoding" {
> r del "{slot}zseta"
> assert_equal 0 [r zunionstore "{slot}dst_key" 1 "{slot}zseta"]
> assert_equal 0 [r exists "{slot}dst_key"]
> }
> {code}
> Enable this test as part of this fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
[
https://issues.apache.org/jira/browse/GEODE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9714:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> CI: QueryConfigurationServiceConstraintsDistributedTest failed with
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> ---
>
> Key: GEODE-9714
> URL: https://issues.apache.org/jira/browse/GEODE-9714
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
> {code:java}
> QueryConfigurationServiceConstraintsDistributedTest > [10]
> indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
> FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 357
> [fatal 2021/10/09 19:11:41.270 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.StoppedSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
> at
> org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at
> org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
> at
> org.apache.geode.internal.cache.LocalRegion.serverDestroy(LocalRegion.java:3095)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforeDestroy(LocalRegion.java:2972)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.destroy(ProxyRegionMap.java:172)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6507)
> at
>
[jira] [Commented] (GEODE-9688) .Net core builds should be x64
[ https://issues.apache.org/jira/browse/GEODE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427936#comment-17427936 ] ASF subversion and git services commented on GEODE-9688: Commit a990bc4a140dc4eb29483c390d1df76b74e062a6 in geode-native's branch refs/heads/develop from Ernie Burghardt [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=a990bc4 ] GEODE-9688: net-core builds only for x64 (#878) * GEODE-9688: net-core builds only for x64 * Fix path for install * Specifiy platform for test runs > .Net core builds should be x64 > -- > > Key: GEODE-9688 > URL: https://issues.apache.org/jira/browse/GEODE-9688 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9688) .Net core builds should be x64
[ https://issues.apache.org/jira/browse/GEODE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427937#comment-17427937 ] ASF GitHub Bot commented on GEODE-9688: --- pdxcodemonkey merged pull request #878: URL: https://github.com/apache/geode-native/pull/878 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > .Net core builds should be x64 > -- > > Key: GEODE-9688 > URL: https://issues.apache.org/jira/browse/GEODE-9688 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9668) AbstractHitsMissesIntegrationTest.testMsetnx is Failing
[ https://issues.apache.org/jira/browse/GEODE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9668: -- Labels: pull-request-available (was: ) > AbstractHitsMissesIntegrationTest.testMsetnx is Failing > --- > > Key: GEODE-9668 > URL: https://issues.apache.org/jira/browse/GEODE-9668 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The AbstractHitsMissesIntegrationTest.testMsetnx test is currently failing. > This test is annotated with @Ignore which we would like to remove. The test > is asserting that stats are not updated but they are being updated and > therefore, the tests is failing. > > +Acceptance Criteria+ > The AbstractHitsMissesIntegrationTest.testMsetnx test is passing and the > @Ignore annotation has been removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9726) Add Redis Command Context to Authorization
Wayne created GEODE-9726: Summary: Add Redis Command Context to Authorization Key: GEODE-9726 URL: https://issues.apache.org/jira/browse/GEODE-9726 Project: Geode Issue Type: Improvement Components: redis Reporter: Wayne As an enterprise security engineer, I would like to integrate Geode for Redis with my corporate security system to determine if a user is authorized to perform a specified command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9698) BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427915#comment-17427915
]
Anthony Baker commented on GEODE-9698:
--
Reviewed and removed triage label.
> BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient
> fails on Windows
>
>
> Key: GEODE-9698
> URL: https://issues.apache.org/jira/browse/GEODE-9698
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> {{BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient()}}
> fails on Windows.
> When a server receives a connection request with an unrecognized client
> version, it sends an informative reply and immediately closes the socket.
> In this situation, the client wants to throw a
> {{ServerRefusedConnectionException}} with a message that includes the
> server's informative reply.
> On Windows, when the client attempts to read the server's reply, the socket
> throws a {{SocketException}} with the message "Connection reset". Further up
> the call stack, {{ConnectionFactoryImpl.createClientToServerConnection()}}
> quietly discards this exception. As a result, the caller never receives the
> informative {{ServerRefusedConnectionException}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9698) BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9698:
-
Labels: (was: needsTriage)
> BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient
> fails on Windows
>
>
> Key: GEODE-9698
> URL: https://issues.apache.org/jira/browse/GEODE-9698
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Dale Emery
>Priority: Major
>
> {{BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient()}}
> fails on Windows.
> When a server receives a connection request with an unrecognized client
> version, it sends an informative reply and immediately closes the socket.
> In this situation, the client wants to throw a
> {{ServerRefusedConnectionException}} with a message that includes the
> server's informative reply.
> On Windows, when the client attempts to read the server's reply, the socket
> throws a {{SocketException}} with the message "Connection reset". Further up
> the call stack, {{ConnectionFactoryImpl.createClientToServerConnection()}}
> quietly discards this exception. As a result, the caller never receives the
> informative {{ServerRefusedConnectionException}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9725:
-
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI
needsTriage pull-request-available)
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427914#comment-17427914
]
Anthony Baker commented on GEODE-9725:
--
Reviewed and removed triage label.
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9701) ClusterStartupRule starts 4 VMs even if fewer VMs is specified
[
https://issues.apache.org/jira/browse/GEODE-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427912#comment-17427912
]
ASF subversion and git services commented on GEODE-9701:
Commit 02e4baaadcd1fe7c076a445aa977b3c604d8eabc in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=02e4baa ]
GEODE-9701: Support lower VM counts in ClusterStartupRule
> ClusterStartupRule starts 4 VMs even if fewer VMs is specified
> --
>
> Key: GEODE-9701
> URL: https://issues.apache.org/jira/browse/GEODE-9701
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Bill reported that ClusterStartupRule seems to be creating 4 VMs no matter
> how few VMs he specifies in a new test for [PR
> #6930|https://github.com/apache/geode/pull/6930]. The concern is that by
> creating more VMs, we are causing unnecessary load on machines in the cloud.
> I wrote this simple test which confirms the problem:
> {noformat}
> import static org.apache.geode.test.dunit.VM.getVMCount;
> import static org.assertj.core.api.Assertions.assertThat;
> import org.junit.Rule;
> import org.junit.Test;
> import org.apache.geode.test.dunit.rules.ClusterStartupRule;
> public class ClusterStartupRuleVmCountDistributedTest {
> @Rule
> public ClusterStartupRule clusterStartupRule = new ClusterStartupRule(3);
> @Test
> public void limitsVMsTo3() {
> assertThat(getVMCount()).isEqualTo(3);
> }
> }
> {noformat}
> But if I replace {{ClusterStartupRule}} with {{DistributedRule}}, it passes
> so the problem is specific to {{ClusterStartupRule}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9725:
--
Labels: GeodeOperationAPI needsTriage pull-request-available (was:
GeodeOperationAPI needsTriage)
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9570) Make sure registered interests will re-authenticate when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9570. Resolution: Fixed > Make sure registered interests will re-authenticate when auth expired > - > > Key: GEODE-9570 > URL: https://issues.apache.org/jira/browse/GEODE-9570 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427899#comment-17427899 ] ASF subversion and git services commented on GEODE-9702: Commit c2b19e38ae7d22b349d20b263f73fae288cf3ce3 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c2b19e3 ] GEODE-9702: Add SPI check to Java API compare build task (#6980) * GEODE-9702: Add SPI check rule to japicmp, with exceptions for current behavior * Update Java API exceptions post 1.14 release. * Drop un-needed exceptions to wan.GatewaySenderFactory API > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9668) AbstractHitsMissesIntegrationTest.testMsetnx is Failing
[ https://issues.apache.org/jira/browse/GEODE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9668: -- Assignee: Donal Evans > AbstractHitsMissesIntegrationTest.testMsetnx is Failing > --- > > Key: GEODE-9668 > URL: https://issues.apache.org/jira/browse/GEODE-9668 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > > The AbstractHitsMissesIntegrationTest.testMsetnx test is currently failing. > This test is annotated with @Ignore which we would like to remove. The test > is asserting that stats are not updated but they are being updated and > therefore, the tests is failing. > > +Acceptance Criteria+ > The AbstractHitsMissesIntegrationTest.testMsetnx test is passing and the > @Ignore annotation has been removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.
[ https://issues.apache.org/jira/browse/GEODE-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior reassigned GEODE-9723: - Assignee: Joris Melchior > Add test to cover transaction based operations when re-authentication happens. > -- > > Key: GEODE-9723 > URL: https://issues.apache.org/jira/browse/GEODE-9723 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI > > add test scenario for when a transaction has multiple operations, what would > happen when auth expired in the middle of a transaction. Would the > transaction continue if re-auth succeeds? Would the resources be cleared up > with re-auth failed? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9717) allow self-service addition of all JDK8 check in PR pipeline when desired
[
https://issues.apache.org/jira/browse/GEODE-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9717:
Description: You can already add the {{windows}} label to a PR to also run
the Windows tests; it would be helpful if you could just add a {{jdk8}} label
to also run [the rest of] the JDK8 tests... (was: You can already add the
{{Windows}} label to a PR to also run the Windows tests; it would be helpful if
you could just add a {{JDK8}} label to also run [the rest of] the JDK8 tests...)
> allow self-service addition of all JDK8 check in PR pipeline when desired
> -
>
> Key: GEODE-9717
> URL: https://issues.apache.org/jira/browse/GEODE-9717
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> You can already add the {{windows}} label to a PR to also run the Windows
> tests; it would be helpful if you could just add a {{jdk8}} label to also run
> [the rest of] the JDK8 tests...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9717) allow self-service addition of all JDK8 check in PR pipeline when desired
[
https://issues.apache.org/jira/browse/GEODE-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-9717.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> allow self-service addition of all JDK8 check in PR pipeline when desired
> -
>
> Key: GEODE-9717
> URL: https://issues.apache.org/jira/browse/GEODE-9717
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> You can already add the {{Windows}} label to a PR to also run the Windows
> tests; it would be helpful if you could just add a {{JDK8}} label to also run
> [the rest of] the JDK8 tests...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9698) BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427891#comment-17427891
]
ASF subversion and git services commented on GEODE-9698:
Commit 7dd614387e9f3133de77ff17675d6bf00051276c in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7dd6143 ]
GEODE-9536: Disable client version test on Windows (#6971)
PROBLEM
When a server receives a connection request with an unrecognized client
version, it sends an informative reply and immediately closes the
socket.
In this situation, the client wants to throw a
`ServerRefusedConnectionException` with a message that includes the
server's informative reply.
On Windows, when the client attempts to read the server's reply, the
socket throws a `SocketException` with the message "Connection reset".
As a result, the caller never receives the informative
`ServerRefusedConnectionException`.
SOLUTION
Disable this test on Windows until the underlying issue is fixed. See
https://issues.apache.org/jira/browse/GEODE-9698
NOTE
This prepares for an upcoming PR to run all distributed tests (except
explicitly ignored ones like these) on Windows.
> BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient
> fails on Windows
>
>
> Key: GEODE-9698
> URL: https://issues.apache.org/jira/browse/GEODE-9698
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> {{BackwardCompatibilityHigherVersionClientDUnitTest.testHigherVersionedClient()}}
> fails on Windows.
> When a server receives a connection request with an unrecognized client
> version, it sends an informative reply and immediately closes the socket.
> In this situation, the client wants to throw a
> {{ServerRefusedConnectionException}} with a message that includes the
> server's informative reply.
> On Windows, when the client attempts to read the server's reply, the socket
> throws a {{SocketException}} with the message "Connection reset". Further up
> the call stack, {{ConnectionFactoryImpl.createClientToServerConnection()}}
> quietly discards this exception. As a result, the caller never receives the
> informative {{ServerRefusedConnectionException}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9536) Run all Windows distributed tests in CI, in parallel
[ https://issues.apache.org/jira/browse/GEODE-9536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427890#comment-17427890 ] ASF subversion and git services commented on GEODE-9536: Commit 7dd614387e9f3133de77ff17675d6bf00051276c in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7dd6143 ] GEODE-9536: Disable client version test on Windows (#6971) PROBLEM When a server receives a connection request with an unrecognized client version, it sends an informative reply and immediately closes the socket. In this situation, the client wants to throw a `ServerRefusedConnectionException` with a message that includes the server's informative reply. On Windows, when the client attempts to read the server's reply, the socket throws a `SocketException` with the message "Connection reset". As a result, the caller never receives the informative `ServerRefusedConnectionException`. SOLUTION Disable this test on Windows until the underlying issue is fixed. See https://issues.apache.org/jira/browse/GEODE-9698 NOTE This prepares for an upcoming PR to run all distributed tests (except explicitly ignored ones like these) on Windows. > Run all Windows distributed tests in CI, in parallel > > > Key: GEODE-9536 > URL: https://issues.apache.org/jira/browse/GEODE-9536 > Project: Geode > Issue Type: Test > Components: ci, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Currently CI runs only a subset of distributed tests on Windows, and it runs > them sequentially. > Change CI to run all distributed tests in Windows, and to run them in > parallel. > This requires changing a small number tests to allow them to run on Windows. > It may require additional changes to allow them to run in parallel on Windows. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9674) Re-auth seems to cause durable clients lose some events when server force the client to disconnect
[ https://issues.apache.org/jira/browse/GEODE-9674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427874#comment-17427874 ] ASF subversion and git services commented on GEODE-9674: Commit e9320c53f77200f8cb7e3274af3b30f5e9711c23 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e9320c5 ] GEODE-9674: fix durable client message loss issue in tests. (#6947) * for caching_proxy region, count the events received instread of the region size * do not try to dispatch residual messages when exception occurred. * add durable client flag when register interest > Re-auth seems to cause durable clients lose some events when server force the > client to disconnect > -- > > Key: GEODE-9674 > URL: https://issues.apache.org/jira/browse/GEODE-9674 > Project: Geode > Issue Type: Sub-task > Components: core >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > We have several intermittent test failures related to durable clients losing > data afternserver force the client to disconnect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9725:
-
Assignee: Dale Emery
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9725:
--
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9717) allow self-service addition of all JDK8 check in PR pipeline when desired
[
https://issues.apache.org/jira/browse/GEODE-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427860#comment-17427860
]
ASF subversion and git services commented on GEODE-9717:
Commit b6f8cc81408502ce9643ad80b33678280ff4b1ca in geode's branch
refs/heads/develop from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b6f8cc8 ]
GEODE-9717: fix to ensure all required PR check jobs are present (#6983)
> allow self-service addition of all JDK8 check in PR pipeline when desired
> -
>
> Key: GEODE-9717
> URL: https://issues.apache.org/jira/browse/GEODE-9717
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Labels: pull-request-available
>
> You can already add the {{Windows}} label to a PR to also run the Windows
> tests; it would be helpful if you could just add a {{JDK8}} label to also run
> [the rest of] the JDK8 tests...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427861#comment-17427861 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell commented on pull request #881: URL: https://github.com/apache/geode-native/pull/881#issuecomment-941283771 The build failures are not due to this PR so putting back to Ready for Review mode. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
Dale Emery created GEODE-9725:
-
Summary: AvailablePort inherently incompatible with default
membership port range
Key: GEODE-9725
URL: https://issues.apache.org/jira/browse/GEODE-9725
Project: Geode
Issue Type: Bug
Components: tests
Affects Versions: 1.15.0
Reporter: Dale Emery
{{AvailablePortHelperIntegrationTest}} failed in CI:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
*Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to retrieve
an "available" port from the membership port range. This feature is both
unnecessary and inherently unreliable.
*Inherently unreliable:* The default membership port range overlaps each OS's
ephemeral port range. An ephemeral port deemed to be "available" by one of
these methods can be put into use by another process even before the method
returns. It is not safe to rely on such a port to remain available after it is
checked.
*Unnecessary:* Currently the only callers that request ports from the
membership port range are two tests in {{DistributedSystemDUnitTest}}. In each
case, the test uses the returned ports to +set+ the membership port range for a
member. There is no need for the ports to come from any particular range.
There are no other uses of this feature, either in the product or in tests.
*Solution:* Remove this feature from {{AvailablePort}} and
{{AvailablePortHelper}}.
*Alternatives:*
* {{DistributedSystemDUnitTest}} can get available ports from the available
port range. This range is safe to use (assuming all other concurrently-running
tests are well-behaved).
* A caller that needs ports in a specific range can call
{{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9725:
-
Labels: needsTriage (was: )
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427854#comment-17427854
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#264|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/264].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Updated] (GEODE-9680) Newly Started/Restarted Locators are Susceptible to Split-Brains
[
https://issues.apache.org/jira/browse/GEODE-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9680:
Description:
The issues described here are present in all versions of Geode (this is not new
to 1.15.0)…
Geode is built on the assumption that views progress linearly in a sequence. If
that sequence ever forks into two or more parallel lines then we have a "split
brain".
In a split brain condition, each of the parallel views are independent. It's as
if you have more than one system running concurrently. It's possible e.g. for
some clients to connect to members of one view and other clients to connect to
members of another view. Updates to members in one view are not seen by members
of a parallel view.
Geode views are produced by a coordinator. As long as only a single coordinator
is running, there is no possibility of a split brain. Split brain arises when
more than one coordinator is producing views at the same time.
Each Geode member (peer) is started with the {{locators}} configuration
parameter. That parameter specifies locator(s) to use to find the (already
running!) coordinator (member) to join with.
When a locator (member) starts, it goes through this sequence to find the
coordinator:
# it first tries to find the coordinator through one of the (other) configured
locators
# if it can't contact any of those, it tries contacting non-locator (cache
server) members it has retrieved from the "view presistence" ({{.dat}}) file
If it hasn't found a coordinator to join with, then the locator may _become_ a
coordinator.
Sometimes this is ok. If no other coordinator is currently running then this
behavior is fine. An example is when an [administrator is starting up a brand
new
cluster|https://geode.apache.org/docs/guide/114/configuring/running/running_the_locator.html].
In that case we want the very first locator we start to become the coordinator.
But there are a number of situations where there may already be another
coordinator running but it cannot be reached:
* if the administrator/operator wants to *start up a brand new cluster* with
multiple locators and…
** maybe Geode is running in a managed environment like Kubernetes and the
locators hostnames are not (yet) resolvable in DNS
** maybe there is a network partition between the starting locators so they
can't communicate
** maybe the existing locators or coordinator are running very slowly or the
network is degraded. This is effectively the same as the network partition just
mentioned
* if a cluster is already running and the administrator/operator wants to
*scale it up* by starting/adding a new locator Geode is susceptible to the same
issues just mentioned
* if a cluster is already running and the administrator/operator needs to
*restart* a locator, e.g. for a rolling upgrade, if none of the locators in the
{{locators}} configuration parameter are reachable (maybe they are not running,
or maybe there is a network partition) and…
** if the "view persistence" {{.dat}} file is missing or deleted
** or if the current set of running Geode members has evolved so far that the
coordinates (host+port) in the {{.dat}} file are completely out of date
In each of those cases, the newly starting locator will become a coordinator
and will start producing views. Now we'll have the old coordinator producing
views at the same time as the new one.
*When this ticket is complete*, Geode will offer a locator startup mode (via
TBD {{LocatorLauncher}} startup parameter) that prevents that locator from
becoming a coordinator. In that mode, it will be possible for an
administrator/operator to avoid many of the problematic scenarios mentioned
above, while retaining the ability (via some _other_ mode) to start a first
locator which is allowed to become a coordinator.
For purposes of discussion we'll call the startup mode that allows the locator
to become a coordinator "seed" mode, and we'll call the new startup mode that
prevents the locator from becoming a coordinator before first joining,
"join-only" mode.
After this mode split is implemented, it is envisioned that to start a brand
new cluster, an administrator/operator will start the first locator in "seed"
mode. After that the operator will start all subsequent locators in "join only"
mode. If network partitions occur during startup, those newly started
("join-only") nodes will exit with a failure status—under no circumstances will
they ever become coordinators.
To add a locator to a running cluster, an operator starts it in "join only"
mode. The new member will similarly either join with an existing coordinator or
exit with a failure status, thereby avoiding split brains.
When an operator restarts a locator, e.g. during a rolling upgrade, they will
restart it in "join only" mode. If a network partition is encountered, or the
{{.dat}} file is missing or
[jira] [Updated] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9038: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8117) ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427850#comment-17427850
]
Geode Integration commented on GEODE-8117:
--
Seen in [windows-core-integration-test-openjdk11
#255|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/255]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0565/test-results/integrationTest/1633997382/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0565/test-artifacts/1633997382/windows-coreintegrationtestfiles-openjdk11-1.15.0-build.0565.tgz].
> ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile fails
> intermittently
>
>
> Key: GEODE-8117
> URL: https://issues.apache.org/jira/browse/GEODE-8117
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase
> expected:<[online]> but was:<[not responding]> within 5 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:211)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:190)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:201)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:131)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:127)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile(ServerLauncherRemoteIntegrationTest.java:91)
> Caused by: org.junit.ComparisonFailure: expected:<[online]> but was:<[not
> responding]>
> at
> jdk.internal.reflect.GeneratedConstructorAccessor25.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(ServerLauncherRemoteIntegrationTestCase.java:213)
> at
> org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:222)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:209)
> at java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ... 1 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427846#comment-17427846
]
Geode Integration commented on GEODE-7489:
--
Seen on support/1.12 in [integration-test-openjdk8
#42|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/integration-test-openjdk8/builds/42]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0290/test-results/integrationTest/1634028366/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0290/test-artifacts/1634028366/integrationtestfiles-openjdk8-1.12.5-build.0290.tgz].
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: no-release-note, pull-request-available
> Fix For: 1.14.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427841#comment-17427841
]
Geode Integration commented on GEODE-9528:
--
Seen on support/1.12 in [integration-test-openjdk11
#54|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/integration-test-openjdk11/builds/54]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0290/test-results/integrationTest/1634028213/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0290/test-artifacts/1634028213/integrationtestfiles-openjdk11-1.12.5-build.0290.tgz].
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8196) CI failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver > luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver failed with
[
https://issues.apache.org/jira/browse/GEODE-8196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427839#comment-17427839
]
Geode Integration commented on GEODE-8196:
--
Seen on support/1.12 in [upgrade-test-openjdk11
#42|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/upgrade-test-openjdk11/builds/42]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0289/test-results/upgradeTest/1633998148/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0289/test-artifacts/1633998148/upgradetestfiles-openjdk11-1.12.5-build.0289.tgz].
> CI failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver >
> luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver failed
> with suspect string
> --
>
> Key: GEODE-8196
> URL: https://issues.apache.org/jira/browse/GEODE-8196
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barrett Oglesby
>Priority: Major
>
> UpgradeTestOpenJDK8 build 210:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/210]
> Failed with:
> {noformat}
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver
> >
> luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver[from_v1.9.1,
> with reindex=false, singleHopEnabled=true] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 8536
> /home/geode/.gradle/caches/modules-2/files-2.1/net.java.[info
> 2020/05/27 22:42:32.456 GMT tid=52] Communication with
> locator /172.17.0.32:21836 failed with java.io.EOFException: Locator at
> /172.17.0.32:21836 did not respond. This is normal if the locator was
> shutdown. If it wasn't check its log for exceptions..
> java.io.EOFException: Locator at /172.17.0.32:21836 did not respond. This
> is normal if the locator was shutdown. If it wasn't check its log for
> exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.EOFException
> at java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427836#comment-17427836
]
Geode Integration commented on GEODE-9528:
--
Seen on support/1.13 in [integration-test-openjdk8
#58|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/integration-test-openjdk8/builds/58]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0605/test-results/integrationTest/1634000381/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0605/test-artifacts/1634000381/integrationtestfiles-openjdk8-1.13.5-build.0605.tgz].
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[
https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427834#comment-17427834
]
Geode Integration commented on GEODE-6284:
--
Seen on support/1.13 in [upgrade-test-openjdk11
#60|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/60]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0605/test-results/upgradeTest/1633996346/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0605/test-artifacts/1633996346/upgradetestfiles-openjdk11-1.13.5-build.0605.tgz].
> CI Failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0,
> with reindex=false]
>
>
> Key: GEODE-6284
> URL: https://issues.apache.org/jira/browse/GEODE-6284
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 34bae3263b09 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:352)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9724: - Labels: needsTriage (was: ) > CI Failure: > RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] > FAILED > --- > > Key: GEODE-9724 > URL: https://issues.apache.org/jira/browse/GEODE-9724 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run > in VM 2 running on Host 05a785bb07ad with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at >
[jira] [Created] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
Eric Shu created GEODE-9724: --- Summary: CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED Key: GEODE-9724 URL: https://issues.apache.org/jira/browse/GEODE-9724 Project: Geode Issue Type: Bug Reporter: Eric Shu org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run in VM 2 running on Host 05a785bb07ad with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) at org.apache.geode.test.dunit.VM.invoke(VM.java:448) at org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) at org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) at org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at
[jira] [Commented] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427831#comment-17427831 ] Geode Integration commented on GEODE-9724: -- Seen on support/1.14 in [upgrade-test-openjdk8 #60|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/upgrade-test-openjdk8/builds/60] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.1-build.0871/test-results/upgradeTest/1633996803/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.1-build.0871/test-artifacts/1633996803/upgradetestfiles-openjdk8-1.14.1-build.0871.tgz]. > CI Failure: > RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] > FAILED > --- > > Key: GEODE-9724 > URL: https://issues.apache.org/jira/browse/GEODE-9724 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run > in VM 2 running on Host 05a785bb07ad with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at >
[jira] [Resolved] (GEODE-9679) Improve Test Coverage for SingleResultCollector
[ https://issues.apache.org/jira/browse/GEODE-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9679. - Fix Version/s: 1.15.0 Resolution: Not A Problem This class no longer exists so code coverage on it is not an issue > Improve Test Coverage for SingleResultCollector > --- > > Key: GEODE-9679 > URL: https://issues.apache.org/jira/browse/GEODE-9679 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Priority: Major > Fix For: 1.15.0 > > > The org.apache.geode.redis.internal.executor.SingleResultCollector has > insufficient test coverage that must be improved. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.
[ https://issues.apache.org/jira/browse/GEODE-9723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9723: --- Labels: GeodeOperationAPI (was: ) > Add test to cover transaction based operations when re-authentication happens. > -- > > Key: GEODE-9723 > URL: https://issues.apache.org/jira/browse/GEODE-9723 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > add test scenario for when a transaction has multiple operations, what would > happen when auth expired in the middle of a transaction. Would the > transaction continue if re-auth succeeds? Would the resources be cleared up > with re-auth failed? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.
Jinmei Liao created GEODE-9723: -- Summary: Add test to cover transaction based operations when re-authentication happens. Key: GEODE-9723 URL: https://issues.apache.org/jira/browse/GEODE-9723 Project: Geode Issue Type: Sub-task Reporter: Jinmei Liao add test scenario for when a transaction has multiple operations, what would happen when auth expired in the middle of a transaction. Would the transaction continue if re-auth succeeds? Would the resources be cleared up with re-auth failed? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9722) Remove the SHUTDOWN redis command
Dan Smith created GEODE-9722: Summary: Remove the SHUTDOWN redis command Key: GEODE-9722 URL: https://issues.apache.org/jira/browse/GEODE-9722 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith This redis command is one of the unsupported operations, which can only be enabled with a system property. Still, we don't want anyone to use this to shutdown a gemfire server and we never intend to add support for it, so we should just delete it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9038: - Component/s: tests > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9038: - Labels: GeodeOperationAPI (was: ) > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-9038: Assignee: Kirk Lund > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9719: -- Labels: pull-request-available (was: ) > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427814#comment-17427814 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell opened a new pull request #881: URL: https://github.com/apache/geode-native/pull/881 This switches the NetCore test framework to Xunit fixtures. A separate fixture is used for each of the test suites (i.e., netcore-integration-test and netcore-session-integration-test. It also just creates an authRegion not separate cluster for the netcore auth tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
[ https://issues.apache.org/jira/browse/GEODE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9721: - Labels: needsTriage (was: ) > the constant names for redis gemfire properties should contain GEODE_FOR_REDIS > -- > > Key: GEODE-9721 > URL: https://issues.apache.org/jira/browse/GEODE-9721 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The following constant names in ConfigurationProperties should all be > renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS > to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, > GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
Darrel Schneider created GEODE-9721: --- Summary: the constant names for redis gemfire properties should contain GEODE_FOR_REDIS Key: GEODE-9721 URL: https://issues.apache.org/jira/browse/GEODE-9721 Project: Geode Issue Type: Bug Components: redis Reporter: Darrel Schneider The following constant names in ConfigurationProperties should all be renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9717) allow self-service addition of all JDK8 check in PR pipeline when desired
[
https://issues.apache.org/jira/browse/GEODE-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427798#comment-17427798
]
ASF subversion and git services commented on GEODE-9717:
Commit 198cc40a2ba69137251ae5a347b8e925bacfe14e in geode's branch
refs/heads/develop from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=198cc40 ]
GEODE-9717: enable self-service jdk8 pr checks via jdk8 pr label (#6979)
> allow self-service addition of all JDK8 check in PR pipeline when desired
> -
>
> Key: GEODE-9717
> URL: https://issues.apache.org/jira/browse/GEODE-9717
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Labels: pull-request-available
>
> You can already add the {{Windows}} label to a PR to also run the Windows
> tests; it would be helpful if you could just add a {{JDK8}} label to also run
> [the rest of] the JDK8 tests...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9717) allow self-service addition of all JDK8 check in PR pipeline when desired
[
https://issues.apache.org/jira/browse/GEODE-9717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9717:
--
Labels: pull-request-available (was: )
> allow self-service addition of all JDK8 check in PR pipeline when desired
> -
>
> Key: GEODE-9717
> URL: https://issues.apache.org/jira/browse/GEODE-9717
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Owen Nichols
>Assignee: Owen Nichols
>Priority: Major
> Labels: pull-request-available
>
> You can already add the {{Windows}} label to a PR to also run the Windows
> tests; it would be helpful if you could just add a {{JDK8}} label to also run
> [the rest of] the JDK8 tests...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427792#comment-17427792
]
ASF subversion and git services commented on GEODE-9645:
Commit 09d840dcc2d4de5996ffc99395b07f35eb38047c in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=09d840d ]
GEODE-9645: mulituserauth don't do dataserializer registrations from client
(#6935)
Don't notify servers of new DataSerializers on the client
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9702: -- Labels: pull-request-available (was: ) > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9720) redis FunctionExecutor classes should be renamed or removed
Darrel Schneider created GEODE-9720: --- Summary: redis FunctionExecutor classes should be renamed or removed Key: GEODE-9720 URL: https://issues.apache.org/jira/browse/GEODE-9720 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider the geode-for-redis implementation has a bunch of classes whose name ends with "FunctionExecutor". These used to actually be implemented using geode functions. But now they are just part of the top level command executor and usually deal with locking down the geode primary bucket and obtaining striped locks. They should be renamed or removed. Renaming is easier but removal also simplifies the code and makes it easier in the future to add more commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9720) redis FunctionExecutor classes should be renamed or removed
[ https://issues.apache.org/jira/browse/GEODE-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9720: --- Assignee: Darrel Schneider > redis FunctionExecutor classes should be renamed or removed > --- > > Key: GEODE-9720 > URL: https://issues.apache.org/jira/browse/GEODE-9720 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > the geode-for-redis implementation has a bunch of classes whose name ends > with "FunctionExecutor". These used to actually be implemented using geode > functions. But now they are just part of the top level command executor and > usually deal with locking down the geode primary bucket and obtaining striped > locks. > They should be renamed or removed. Renaming is easier but removal also > simplifies the code and makes it easier in the future to add more commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427785#comment-17427785 ] Dan Smith commented on GEODE-9718: -- I think maybe a better option might be to use a lock for the cluster configuration. We can make the request to get the cluster config wait until the update to the cluster config is completely applied. > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > > Mail discussion: [Region is not created on one of the > servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9600) Add Programmatic Cluster Support to NetCore.Test
[ https://issues.apache.org/jira/browse/GEODE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427772#comment-17427772 ] ASF subversion and git services commented on GEODE-9600: Commit 620479a5069a7c97956cdf46f2b0f69384ff6b94 in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=620479a ] GEODE-9600: Add Cluster Support to NetCore Test Framework (#880) * Add cluster support to netcore-integration-test and netcore-session integration-test * Add top level solution for netcore * Add programmatic cluster files in shared folder for use by both test projects * Address Rat check issue: Add using statement to new Process * Remove gfsh based cluster scripts, now supported in cluster.cs, etc. * Update refs to Cluster.cs, etc. in project files * cmake configure Config.cs.in so environment vars are not required * Remove old netcore solution file * Cleanup per review: Geode .Net Core, not .net Core > Add Programmatic Cluster Support to NetCore.Test > > > Key: GEODE-9600 > URL: https://issues.apache.org/jira/browse/GEODE-9600 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > We just need to bring a few files over from the new clicache test framework > (clicache/integration-test2): > * Cluster.cs > * Gfsh.cs > * GfshExecute.cs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9600) Add Programmatic Cluster Support to NetCore.Test
[ https://issues.apache.org/jira/browse/GEODE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427771#comment-17427771 ] ASF GitHub Bot commented on GEODE-9600: --- mmartell merged pull request #880: URL: https://github.com/apache/geode-native/pull/880 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Programmatic Cluster Support to NetCore.Test > > > Key: GEODE-9600 > URL: https://issues.apache.org/jira/browse/GEODE-9600 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > We just need to bring a few files over from the new clicache test framework > (clicache/integration-test2): > * Cluster.cs > * Gfsh.cs > * GfshExecute.cs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9634: -- Labels: pull-request-available (was: ) > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Blocker > Labels: pull-request-available > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427742#comment-17427742 ] ASF GitHub Bot commented on GEODE-9634: --- pdxcodemonkey merged pull request #872: URL: https://github.com/apache/geode-native/pull/872 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Blocker > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9634) Wan replication between clusters on localhost broken by change to IP lookup
[ https://issues.apache.org/jira/browse/GEODE-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427740#comment-17427740 ] ASF subversion and git services commented on GEODE-9634: Commit faa96d094fe455a60bceeeb9e21c16cafb81af06 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=faa96d0 ] GEODE-9634: Workaround for failing test. (#872) * Updates test. * Fixes hostname issues with tests. * Fix default locator address init. > Wan replication between clusters on localhost broken by change to IP lookup > --- > > Key: GEODE-9634 > URL: https://issues.apache.org/jira/browse/GEODE-9634 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Blocker > > This was the fix for GEODE-8955 (PR #6045). Here's a description from the > start of the Slack discussion thread: > "PR 6045 made on geode-wan LocatorHelper class seems to have broken WAN > replication between two clusters on localhost. I get the ridiculous nature of > WAN over localhost. Is it intentional that localhost is replaced with a local > interface IP by the changes made in the PR? The result is a test in the > geode-native pipeline does not work anymore since one site can’t see the > other since the locators are bound to localhost but trying to connection to > each other on a non-localhost IP address. Did we run into this same issue on > any of our Java based tests?" > Need to determine if this is desired behavior or not. If not, the old > behavior should be restored. If so, geode native team needs a JIRA ticket to > fix their Wan integration test(s) in CI, where this issue was detected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-9591. - Fix Version/s: 1.15.0 Resolution: Fixed > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-9591. --- > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427710#comment-17427710 ] ASF GitHub Bot commented on GEODE-9591: --- pdxcodemonkey merged pull request #866: URL: https://github.com/apache/geode-native/pull/866 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427709#comment-17427709 ] ASF subversion and git services commented on GEODE-9591: Commit fafa3be8f361bf696b0804f569b890826e242c7f in geode-native's branch refs/heads/develop from Jakov Varenina [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=fafa3be ] GEODE-9591: Don't retry function when Function.isHA=false (#866) * GEODE-9591: Don't retry function when Function.isHA=false Fault: Client clears result by calling ResultCollector::clearResult and re-executes the function even thought Function.isHa() is set to false. Fix: Client will not clear result and retry the function, but it will fail with the received exception from server. Added integration test: 1.FunctionExecutionTest.testThatFunctionExecutionThrowsExceptionNonHAWithFilter 2.FunctionExecutionTest.testThatFunctionExecutionThrowsExceptionNonHA The integration test reproduces the problem in a following way: 1. Populate region so that all buckets are created 2. Shutdown one of the three available servers 3. Peforme rebalance operation, so that buckets are recovered on running servers 4. Execute the function. Function execution will fail with the InternalFunctionInvocationTargetException exception, because client will try to execute single hop function with old PR meatada information (PR metadata received before the rebalance operation). * ASSERT_THROW used instead of try-catch * Check whether isHA==false before clearing results It is possible that function exeuction fail on multiple servers, and in that case only first exception will be thrown, and any subsequent exeception will be ignored. Additionally result should not be cleared in any case when isHa==false. * Rebalance cmd was not executed Test cases are changed to do rebalance operation after new server is introduced in cluster. * Client metadata wasn't complete when function is executed Since client metadata was not complete the function was not exectued in a single hop manner, and therfore exeption is not reproduced. This commit is fixed in a way that now client is connected to only one server. This way client metadata will be updated more frequently, and client metadata will be complete when function is executed. > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
[
https://issues.apache.org/jira/browse/GEODE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427704#comment-17427704
]
ASF GitHub Bot commented on GEODE-9553:
---
pdxcodemonkey merged pull request #879:
URL: https://github.com/apache/geode-native/pull/879
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Review and eliminate all remaining usage of sprintf, snprintf, etc
> --
>
> Key: GEODE-9553
> URL: https://issues.apache.org/jira/browse/GEODE-9553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> From time to time, we will pick up a new version of a compiler on one or
> another platform we build on, and get new complaints about potential buffer
> overflows or other assorted badness around persistent use of sprintf. See
> the following pull request, e.g.:
> https://github.com/apache/geode-native/pull/861
> Fixing these when they come up is good as far as it goes, but we're really
> just applying band-aids to the problem. *All* use of sprintf is bad,
> snprintf only slightly less so. Someone needs to just go through the code
> and rewrite all instances in modern C++ using std::string, std::stringstream,
> etc.
> At a glance, here is the list of remaining files containing calls to sprintf:
> {code}
> c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
> cppcache\integration\test\ThinClientConflation.cpp
> cppcache\integration-test\fw_dunit.cpp
> cppcache\integration-test\testCacheless.cpp
> cppcache\integration-test\testOverflowPutGetSqLite.cpp
> cppcache\integration-test\testRegionMap.cpp
> cppcache\integration-test\testSerialization.cpp
> cppcache\integration-test\testThinClientBigValue.cpp
> cppcache\integration-test\testThinClientCacheablesLimits.cpp
> cppcache\integration-test\testThinClientCacheableStringArray.cpp
> cppcache\integration-test\testThinClientConflation.cpp
> cppcache\integration-test\testThinClientCq.cpp
> cppcache\integration-test\testThinClientCqDurable.cpp
> cppcache\integration-test\testThinClientCqFailover.cpp
> cppcache\integration-test\testThinClientCqHAFailover.cpp
> cppcache\integration-test\testThinClientCqIR.cpp
> cppcache\integration-test\testThinClientDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientGetInterests.cpp
> cppcache\integration-test\testThinClientHADistOps.cpp
> cppcache\integration-test\testThinClientHAEventIDMap.cpp
> cppcache\integration-test\testThinClientHAFailover.cpp
> cppcache\integration-test\testThinClientHAFailoverRegex.cpp
> cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
> cppcache\integration-test\testThinClientHAPeriodicAck.cpp
> cppcache\integration-test\testThinClientHeapLRU.cpp
> cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
> cppcache\integration-test\testThinClientInterestNotify.cpp
> cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
> cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
> cppcache\integration-test\testThinClientLRUExpiration.cpp
> cppcache\integration-test\testThinClientMultiDS.cpp
> cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
> cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientPdxInstance.cpp
> cppcache\integration-test\testThinClientPoolAttrTest.cpp
> cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
> cppcache\integration-test\testThinClientPoolRedundancy.cpp
> cppcache\integration-test\testThinClientPRPutAllFailover.cpp
> cppcache\integration-test\testThinClientRemoteQueryRS.cpp
> cppcache\integration-test\testThinClientRemoteQuerySS.cpp
> cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
> cppcache\integration-test\testThinClientRemoveOps.cpp
> cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
> cppcache\integration-test\testXmlCacheCreationWithPools.cpp
> cppcache\integration-test\testXmlCacheInitialization.cpp
> tests\cpp\security\PkcsCredentialGenerator.cpp
> tests\cpp\security\XmlAuthzCredentialGenerator.cpp
> tests\cpp\testobject\BatchObject.cpp
> tests\cpp\testobject\DeltaPSTObject.cpp
> tests\cpp\testobject\DeltaTestImpl.cpp
> tests\cpp\testobject\EqStruct.cpp
> tests\cpp\testobject\FastAssetAccount.cpp
>
[jira] [Commented] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
[
https://issues.apache.org/jira/browse/GEODE-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427702#comment-17427702
]
ASF subversion and git services commented on GEODE-9553:
Commit 7eed9d3868118f5f0d1d93f75c2a4b64ddb7cead in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7eed9d3 ]
GEODE-9553: remove usage of sprintf from tests (#879)
> Review and eliminate all remaining usage of sprintf, snprintf, etc
> --
>
> Key: GEODE-9553
> URL: https://issues.apache.org/jira/browse/GEODE-9553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> From time to time, we will pick up a new version of a compiler on one or
> another platform we build on, and get new complaints about potential buffer
> overflows or other assorted badness around persistent use of sprintf. See
> the following pull request, e.g.:
> https://github.com/apache/geode-native/pull/861
> Fixing these when they come up is good as far as it goes, but we're really
> just applying band-aids to the problem. *All* use of sprintf is bad,
> snprintf only slightly less so. Someone needs to just go through the code
> and rewrite all instances in modern C++ using std::string, std::stringstream,
> etc.
> At a glance, here is the list of remaining files containing calls to sprintf:
> {code}
> c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
> cppcache\integration\test\ThinClientConflation.cpp
> cppcache\integration-test\fw_dunit.cpp
> cppcache\integration-test\testCacheless.cpp
> cppcache\integration-test\testOverflowPutGetSqLite.cpp
> cppcache\integration-test\testRegionMap.cpp
> cppcache\integration-test\testSerialization.cpp
> cppcache\integration-test\testThinClientBigValue.cpp
> cppcache\integration-test\testThinClientCacheablesLimits.cpp
> cppcache\integration-test\testThinClientCacheableStringArray.cpp
> cppcache\integration-test\testThinClientConflation.cpp
> cppcache\integration-test\testThinClientCq.cpp
> cppcache\integration-test\testThinClientCqDurable.cpp
> cppcache\integration-test\testThinClientCqFailover.cpp
> cppcache\integration-test\testThinClientCqHAFailover.cpp
> cppcache\integration-test\testThinClientCqIR.cpp
> cppcache\integration-test\testThinClientDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientGetInterests.cpp
> cppcache\integration-test\testThinClientHADistOps.cpp
> cppcache\integration-test\testThinClientHAEventIDMap.cpp
> cppcache\integration-test\testThinClientHAFailover.cpp
> cppcache\integration-test\testThinClientHAFailoverRegex.cpp
> cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
> cppcache\integration-test\testThinClientHAPeriodicAck.cpp
> cppcache\integration-test\testThinClientHeapLRU.cpp
> cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
> cppcache\integration-test\testThinClientInterestNotify.cpp
> cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
> cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
> cppcache\integration-test\testThinClientLRUExpiration.cpp
> cppcache\integration-test\testThinClientMultiDS.cpp
> cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
> cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
> cppcache\integration-test\testThinClientPdxInstance.cpp
> cppcache\integration-test\testThinClientPoolAttrTest.cpp
> cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
> cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
> cppcache\integration-test\testThinClientPoolRedundancy.cpp
> cppcache\integration-test\testThinClientPRPutAllFailover.cpp
> cppcache\integration-test\testThinClientRemoteQueryRS.cpp
> cppcache\integration-test\testThinClientRemoteQuerySS.cpp
> cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
> cppcache\integration-test\testThinClientRemoveOps.cpp
> cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
> cppcache\integration-test\testXmlCacheCreationWithPools.cpp
> cppcache\integration-test\testXmlCacheInitialization.cpp
> tests\cpp\security\PkcsCredentialGenerator.cpp
> tests\cpp\security\XmlAuthzCredentialGenerator.cpp
> tests\cpp\testobject\BatchObject.cpp
> tests\cpp\testobject\DeltaPSTObject.cpp
> tests\cpp\testobject\DeltaTestImpl.cpp
> tests\cpp\testobject\EqStruct.cpp
> tests\cpp\testobject\FastAssetAccount.cpp
> tests\cpp\testobject\InvalidPdxUsage.cpp
> tests\cpp\testobject\NestedPdxObject.cpp
> tests\cpp\testobject\PdxClassV1.cpp
> tests\cpp\testobject\PdxClassV2.cpp
>
[jira] [Commented] (GEODE-9600) Add Programmatic Cluster Support to NetCore.Test
[
https://issues.apache.org/jira/browse/GEODE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427682#comment-17427682
]
ASF GitHub Bot commented on GEODE-9600:
---
mmartell commented on a change in pull request #880:
URL: https://github.com/apache/geode-native/pull/880#discussion_r727147285
##
File path: netcore/netcore-integration-test/CacheFactoryTest.cs
##
@@ -16,10 +16,16 @@
*/
using System;
using Xunit;
+using Xunit.Abstractions;
-namespace Apache.Geode.Client {
+namespace Apache.Geode.Client.IntegrationTests
+{
[Collection("Geode .net Core Collection")]
Review comment:
Tests can be run from the Test Explorer in the IDE, or from the command
line exactly like the CI.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add Programmatic Cluster Support to NetCore.Test
>
>
> Key: GEODE-9600
> URL: https://issues.apache.org/jira/browse/GEODE-9600
> Project: Geode
> Issue Type: Test
> Components: native client
>Reporter: Michael Martell
>Assignee: Michael Martell
>Priority: Major
> Labels: pull-request-available
>
> We just need to bring a few files over from the new clicache test framework
> (clicache/integration-test2):
> * Cluster.cs
> * Gfsh.cs
> * GfshExecute.cs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
Michael Martell created GEODE-9719: -- Summary: Switch .NET Core Tests to Xunit Fixtures Key: GEODE-9719 URL: https://issues.apache.org/jira/browse/GEODE-9719 Project: Geode Issue Type: Test Components: native client Reporter: Michael Martell The programmatic cluster support brought in by [GEODE-9600|http://example.com] currently starts and stops the geode cluster for each test. This ticket is to switch the tests to an Xunit fixture model wherein all tests for netcore-lib will be run against a single cluster start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9641) Benchmark instability in P2pPartitionedPutBytesBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami resolved GEODE-9641.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Benchmark instability in P2pPartitionedPutBytesBenchmark
>
>
> Key: GEODE-9641
> URL: https://issues.apache.org/jira/browse/GEODE-9641
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> P2pPartitionedPutBytesBenchmark started failing in CI after the fix for
> GEODE-9204 was merged.
> {code:java}
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark
> average ops/second Baseline:179582.83 Test:170268.31
> Difference: -5.2%
>ops/second standard error Baseline: 849.15 Test: 649.44
> Difference: -23.5%
>ops/second standard deviation Baseline: 25346.86 Test: 19374.76
> Difference: -23.6%
> YS 99th percentile latency Baseline: 5010.00 Test: 5110.00
> Difference: +2.0%
> median latency Baseline: 2416639.00 Test: 2412543.00
> Difference: -0.2%
> 90th percentile latency Baseline: 4698111.00 Test: 4567039.00
> Difference: -2.8%
> 99th percentile latency Baseline: 38141951.00 Test: 81723391.00
> Difference: +114.3%
>99.9th percentile latency Baseline: 196214783.00 Test: 205389823.00
> Difference: +4.7%
> average latency Baseline: 4033453.68 Test: 4258029.39
> Difference: +5.6%
> latency standard deviation Baseline: 14549153.77 Test: 15673393.37
> Difference: +7.7%
> latency standard error Baseline: 1149.00 Test: 1271.79
> Difference: +10.7%
> average ops/second Baseline:533863.27 Test:505986.13
> Difference: -5.2%
> BENCHMARK FAILED:
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark average
> latency is 5% worse than baseline.{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-9718: -- Description: We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. Mail discussion: [Region is not created on one of the servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] was: We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster
[jira] [Created] (GEODE-9718) The region is not created on all servers if commands are run in parallel
Mario Kevo created GEODE-9718: - Summary: The region is not created on all servers if commands are run in parallel Key: GEODE-9718 URL: https://issues.apache.org/jira/browse/GEODE-9718 Project: Geode Issue Type: Bug Reporter: Mario Kevo We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9718: - Labels: needsTriage (was: ) > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
