[jira] [Commented] (GEODE-10216) Add test for existence of VM stats
[
https://issues.apache.org/jira/browse/GEODE-10216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517757#comment-17517757
]
ASF subversion and git services commented on GEODE-10216:
-
Commit de91e330525b7e87a1bd20bb162601fe6e2301f6 in geode's branch
refs/heads/develop from Hale Bales
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=de91e33052 ]
GEODE-10216: Add test for existence of VM stats (#7551)
When we started running with JDK 11, some users noticed that a few stats had
gone missing. There was a one line fix in test.gradle that was added as part of
a bigger effort, but the change was not tested. This adds a test for the
existence of the VM stats so that none of the stats go missing in the future.
also changes all the assertions to use assertj.
> Add test for existence of VM stats
> --
>
> Key: GEODE-10216
> URL: https://issues.apache.org/jira/browse/GEODE-10216
> Project: Geode
> Issue Type: Test
> Components: statistics
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> When we started running with JDK 11, a couple of stats went missing (fdsOpen
> and fdLimit). This was resolved by adding the following line to test.gradle:
> {code:java}
> "--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED",
> {code}
> This change was not tested. Add a test so that if something similar happens
> in the future, we will know about it before a customer has an issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Hufnagel resolved GEODE-10205.
--
Fix Version/s: 1.15.0
1.14.4
Resolution: Fixed
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.14.4
>
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9142) Make disk size for heavy lifters parameterized
[ https://issues.apache.org/jira/browse/GEODE-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9142. - Fix Version/s: 1.12.10 1.13.9 1.14.0 Resolution: Fixed > Make disk size for heavy lifters parameterized > -- > > Key: GEODE-9142 > URL: https://issues.apache.org/jira/browse/GEODE-9142 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.0 > > > We're running out of disk space on certain jobs. Make it so we can choose how > much disk to allocate on a per job basis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517751#comment-17517751
]
ASF subversion and git services commented on GEODE-10205:
-
Commit 924d3555c8265b8c5e2a7ad93547ba6f12f73109 in geode-site's branch
refs/heads/asf-site from Max Hufnagel
[ https://gitbox.apache.org/repos/asf?p=geode-site.git;h=924d3555 ]
GEODE-10205: Correct Java API method from getDiskStore to findDiskStore (#16)
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517750#comment-17517750
]
ASF GitHub Bot commented on GEODE-10205:
davebarnes97 merged PR #16:
URL: https://github.com/apache/geode-site/pull/16
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Hufnagel reassigned GEODE-10205:
Assignee: Max Hufnagel
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10003) Support JDK 17 on Geode
[ https://issues.apache.org/jira/browse/GEODE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-10003: - Labels: Java17 jdk17 (was: jdk17) > Support JDK 17 on Geode > --- > > Key: GEODE-10003 > URL: https://issues.apache.org/jira/browse/GEODE-10003 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: Java17, jdk17 > > JDK 17 Schedule: [https://openjdk.java.net/projects/jdk/17/] > The first ticket to suggest going beyond JDK8 was GEODE-3. Now that JDK17 is > LTS, and Spring and other users are embracing JDK17, Geode should at least > run (if not compile) on JDK17. > This may take a lot of work, possibly requiring a new major release. Please > add subtasks to this ticket as necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9889:
-
Labels: redis-triage (was: needsTriage)
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: redis-triage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-3492) ServerLauncherRemoteFileIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-3492:
-
Labels: IntegrationTest Windows (was: IntegrationTest Windows needsTriage)
> ServerLauncherRemoteFileIntegrationTest fails on Windows
>
>
> Key: GEODE-3492
> URL: https://issues.apache.org/jira/browse/GEODE-3492
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidReturnsStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidReturnsStopped(ServerLauncherRemoteFileIntegrationTest.java:75)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidDeletesPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidDeletesPidFile(ServerLauncherRemoteFileIntegrationTest.java:63)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidStopsServerProcess FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
>
[jira] [Updated] (GEODE-8641) CI Failure: PartitionedIndexedQueryBenchmark.run
[
https://issues.apache.org/jira/browse/GEODE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-8641:
-
Labels: (was: needsTriage)
> CI Failure: PartitionedIndexedQueryBenchmark.run
>
>
> Key: GEODE-8641
> URL: https://issues.apache.org/jira/browse/GEODE-8641
> Project: Geode
> Issue Type: Test
> Components: benchmarks, tests
>Reporter: Jens Deppe
>Priority: Major
>
> Benchmarking looks like some internal error:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/406
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9987) Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
[
https://issues.apache.org/jira/browse/GEODE-9987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9987:
-
Labels: pull-request-available (was: needsTriage pull-request-available)
> Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
>
>
> Key: GEODE-9987
> URL: https://issues.apache.org/jira/browse/GEODE-9987
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal
> with 4 VMs
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 458
> [fatal 2022/01/22 17:02:39.638 UTC receiver,heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204-65003> tid=125]
> Membership service failure: Member isn't responding to heartbeat requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> ...
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.distributed.HostedLocatorsDUnitTest.testGetAllHostedLocators(HostedLocatorsDUnitTest.java:92)
> Caused by:
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204(heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal_HostedLocatorsDUnitTest_testGetAllHostedLocators-3:115919:locator):59339
> started at Sat Jan 22 17:02:21 UTC 2022: Member isn't responding to
> heartbeat requests, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
>
[jira] [Updated] (GEODE-10056) Gateway-reciver connection load mantained only on one locator
[
https://issues.apache.org/jira/browse/GEODE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10056:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Gateway-reciver connection load mantained only on one locator
> -
>
> Key: GEODE-10056
> URL: https://issues.apache.org/jira/browse/GEODE-10056
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> The first problem is that servers send incorrect gateway-receiver connection
> load to locators with CacheServerLoadMessage. The second problem is that the
> locator doesn't refresh gateway-receivers load per server in the local map
> with the load received in CacheServerLoadMessage. This seems to be a bug, as
> there is already a mechanism to track and store gateway-receiver connection
> load per server in the locator, but that load is never refreshed by a fault
> at the reception of CacheServerLoadMessage. Currently, receiver load is only
> refreshed/increased on the locator that is handling
> ClientConnectionRequest\{group=__recv_group...} and ClientConnectionResponse
> messages from a remote server that is trying to establish gateway sender
> connection. All other locators in a cluster will never refresh the
> gateway-receiver connection load in this case. When the locator that was
> serving remote gateway-senders goes down then a new locator will take that
> job. Problem is that the new locator will not have a correct load (it was
> never refreshed) and that would in most situations result in new
> gateway-sender connections being established in an unbalanced way.
> Way to reproduce the issue:
> Start 2 clusters, Let's call site1 the sending and site2 the receiving site,
> The receiving site should have at least 2 locators. Both have 2 servers. No
> regions are needed.
> Cluster-1 gfsh>list members
> Member Count : 3Name | Id
> - | -
> locator10 | 10.0.2.15(locator10:7332:locator):41000 [Coordinator]
> server11 | 10.0.2.15(server11:8358):41003
> server12 | 10.0.2.15(server12:8717):41005
>
> Cluster-2 gfsh>list members
> Member Count : 4Name | Id
> - | -
> locator10 | 10.0.2.15(locator10:7562:locator):41001 [Coordinator]
> locator11 | 10.0.2.15(locator11:8103:locator):41002
> server11 | 10.0.2.15(server11:8547):41004
> server12 | 10.0.2.15(server12:8908):41006
>
> Create GW receiver in Site2 on both servers.
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section Member | Port | Sender
> Count | Senders Connected
> -- | | | -
> 10.0.2.15(server11:8547):41004 | 5175 | 0 |
> 10.0.2.15(server12:8908):41006 | 5457 | 0 |
> Create GW sender in Site1 on both servers. Use 10 dispatcher threads for
> easier obervation.
> Cluster-1 gfsh>list gateways
> GatewaySender SectionGatewaySender Id | Member |
> Remote Cluster Id | Type | Status | Queued Events |
> Receiver Location
> | -- | - |
> | - | - | -
> senderTo2 | 10.0.2.15(server11:8358):41003 | 2 |
> Parallel | Running and Connected | 0 | 10.0.2.15:5457
> senderTo2 | 10.0.2.15(server12:8717):41005 | 2 |
> Parallel | Running and Connected | 0 | 10.0.2.15:5457
>
> Observe balance in GW receiver connections in Site2. It will be perfect.
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section Member | Port | Sender
> Count | Senders Connected
> -- | | |
> -
> 10.0.2.15(server11:8547):41004 | 5175 | 12 |
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:8717):41005,
> 10.0.2.15(server11:8358):41003, 10.0.2.15(server11:..
> 10.0.2.15(server12:8908):41006 | 5457 | 12 |
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:8717):41005,
> 10.0.2.15(server12:8717):41005, 10.0.2.15(server12:..
>
> 12 connections each - 10 payload + 2 ping connections.
> Now stop GW receiver in one server of site2. In Site1 do a stop/start
> gateway-sender command - all connections will go to the only receiver in
> site2 (as expected). Check it:
>
> Cluster-2 gfsh>list gateways
> GatewayReceiver Section
[jira] [Updated] (GEODE-10095) TcrConnection::readHandshakeData reads too many bytes
[ https://issues.apache.org/jira/browse/GEODE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10095: -- Labels: (was: needsTriage) > TcrConnection::readHandshakeData reads too many bytes > - > > Key: GEODE-10095 > URL: https://issues.apache.org/jira/browse/GEODE-10095 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Matthew Reddington >Priority: Major > > This method is called to read bytes from a socket, and return said data in a > `std::vector`. For some inexplicable (inexcusable?) reason, the > method always adds a 0 byte to the end of the vector, as if it were > null-terminating a string. So, `readHandshakeData(1)` returns 2 bytes, > `readHandshakeData(5)` returns 6 bytes, etc. > This is extremely misleading, given the name of the method and the fact that > the requested number of bytes is a parameter passed in. Also, in no > circumstance is this method used to actually read a string, i.e. something > that may require null-termination. Please remove the extra byte from the > returned vector, and if possible add a unit test to the suite that reads _n_ > bytes and asserts that the method always returns _n_ bytes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10012:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Avoid retries for non-HA function execution
> ---
>
> Key: GEODE-10012
> URL: https://issues.apache.org/jira/browse/GEODE-10012
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *GIVEN* a cluster with 3 servers and 1 locator
> *AND* a PartitionedRegion with redundant-copies="1"
> *AND* a user-defined Function with isHA=false
> *AND* a geode-native client with a pool with single-hop enabled and retry
> attempts set to 2
> *WHEN* execution fails due to a connectivity issue/connection
> timeout/internal cluster error
> *THEN* function is retried twice
>
> *Additional information.* The function is retried at the network code layer,
> and given whenever there is a timeout/connectivity error, the BSL is removed
> from the ClientMetadataService, whenever retries happen, you might get a
> *InternalFunctionInvocationTargetException* exception thrown indicating:
> {code:java}
> Multiple target nodes found for single hop operation {code}
> Also, have into account that Java client API behaviour never retries a
> Function Execution if isHA=false for that function, and whenever isHA=true,
> the function is retried but on the function execution logic and not at the
> networking layer.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10017:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9753: - Labels: pull-request-available (was: needsTriage pull-request-available) > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10217:
--
Labels: (was: needsTriage)
> Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
> -
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
> Byte Buddy could not instrument all classes within the mock's type hierarchy.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
> 10:19:40at
>
[jira] [Updated] (GEODE-10208) Support branches fail to run geode-connectors acceptanceTests due to stale dependency
[
https://issues.apache.org/jira/browse/GEODE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10208:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> Support branches fail to run geode-connectors acceptanceTests due to stale
> dependency
> -
>
> Key: GEODE-10208
> URL: https://issues.apache.org/jira/browse/GEODE-10208
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Attempting to execute geode-connectors:acceptanceTests on support/1.12 or
> 1.13 results in failures with message:
> {noformat}
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No such
> image: quay.io/testcontainers/ryuk:0.2.3"}
> {noformat}
> These support branches are using testcontainers version 1.13. Versions prior
> to 1.14.3 are no longer available anywhere:
> https://stackoverflow.com/questions/61887363/testcontainers-cant-pull-ryuk-image-quay-io-is-not-reachable
> All branches need to be updated to use 1.14.3 or later.
> {noformat}
> > Task :geode-connectors:acceptanceTest
> org.apache.geode.connectors.jdbc.MySqlJdbcWriterIntegrationTest > classMethod
> FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.MySqlJdbcDistributedTest > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.PostgresJdbcLoaderIntegrationTest >
> classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.internal.PostgresTableMetaDataManagerIntegrationTest
> > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> org.apache.geode.connectors.jdbc.internal.MySqlTableMetaDataManagerIntegrationTest
> > classMethod FAILED
> com.github.dockerjava.api.exception.NotFoundException: {"message":"No
> such image: quay.io/testcontainers/ryuk:0.2.3"}
> > Task :geode-redis:acceptanceTest
> org.apache.geode.redis.ExpireNativeRedisAcceptanceTest > classMethod FAILED
> org.testcontainers.containers.ContainerLaunchException: Container startup
> failed
> at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:322)
> at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:302)
> at
> org.apache.geode.redis.ExpireNativeRedisAcceptanceTest.setUp(ExpireNativeRedisAcceptanceTest.java:43)
> Caused by:
> org.testcontainers.containers.ContainerFetchException: Can't get
> Docker image:
> RemoteDockerImage(imageNameFuture=java.util.concurrent.CompletableFuture@28de948a[Completed
> normally], imagePullPolicy=DefaultPullPolicy(),
> dockerClient=LazyDockerClient.INSTANCE)
> at
> org.testcontainers.containers.GenericContainer.getDockerImageName(GenericContainer.java:1265)
> at
> org.testcontainers.containers.GenericContainer.logger(GenericContainer.java:600)
> at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:311)
> ... 2 more
> Caused by:
> com.github.dockerjava.api.exception.NotFoundException:
> {"message":"No such image: quay.io/testcontainers/ryuk:0.2.3"}
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:281)
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.execute(OkHttpInvocationBuilder.java:265)
> at
> org.testcontainers.dockerclient.transport.okhttp.OkHttpInvocationBuilder.post(OkHttpInvocationBuilder.java:136)
> at
> com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:33)
> at
> com.github.dockerjava.core.exec.CreateContainerCmdExec.execute(CreateContainerCmdExec.java:13)
> at
> com.github.dockerjava.core.exec.AbstrSyncDockerCmdExec.exec(AbstrSyncDockerCmdExec.java:21)
> at
> com.github.dockerjava.core.command.AbstrDockerCmd.exec(AbstrDockerCmd.java:35)
> at
> com.github.dockerjava.core.command.CreateContainerCmdImpl.exec(CreateContainerCmdImpl.java:1139)
> at
> org.testcontainers.utility.ResourceReaper.start(ResourceReaper.java:91)
> at
> org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:155)
>
[jira] [Commented] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517736#comment-17517736
]
Anilkumar Gingade commented on GEODE-10215:
---
[~jvarenina]Are you working/fixing on this issue.
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10215:
--
Labels: needsTriage (was: needs)
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10215:
--
Labels: needs (was: needsTriage)
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: needs
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10188) AvailablePortHelperIntegrationTest > initializeUniquePortRange_returnSamePortsForSameRange gets different ports on subsequent tries
[
https://issues.apache.org/jira/browse/GEODE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10188:
--
Labels: (was: needsTriage)
> AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange gets different ports on
> subsequent tries
> ---
>
> Key: GEODE-10188
> URL: https://issues.apache.org/jira/browse/GEODE-10188
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.9
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14294054]
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange(useMembershipPortRange=true)
> FAILED
> org.junit.ComparisonFailure: expected:<[460[10, 46011, 4601]2]> but
> was:<[460[00, 46001, 4600]2]>
> 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.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_returnSamePortsForSameRange(AvailablePortHelperIntegrationTest.java:322)
> 4023 tests completed, 1 failed, 82 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-results/integrationTest/1648509410/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-artifacts/1648509410/integrationtestfiles-openjdk11-1.13.9-build.0668.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10205:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10189) Errors encountered during Apache Geode upgrade
[
https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10189:
--
Labels: (was: needsTriage)
> Errors encountered during Apache Geode upgrade
> --
>
> Key: GEODE-10189
> URL: https://issues.apache.org/jira/browse/GEODE-10189
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.1
>Reporter: Swetha Sudheesh
>Priority: Critical
>
> We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1*
> version to avoid any vulnerabilities. We also added all the dependencies
> mentioned in the Maven with the latest versions. Our application uses {*}JDK
> 11{*}. We faced few issues such as the one described below:
>
> Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
> at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
> at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
> at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
>
> Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
> wrong class: UUID*
> at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
> ... 17 more
> Please let us know why we are encountering this error and how can it be
> resolved? Also let us know the right dependencies that need to be added for
> Apache Geode 1.14.1 upgrade.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10195) MicrometerBinderTest > processorMetricsBinderExists FAILED
[
https://issues.apache.org/jira/browse/GEODE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10195:
--
Labels: (was: needsTriage)
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> --
>
> Key: GEODE-10195
> URL: https://issues.apache.org/jira/browse/GEODE-10195
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
>
> windows-acceptance-test-openjdk11 failed with the following error.
>
> {noformat}
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-ceacbfa8-6147-51ca-affd-b497cd16e2ef(4420:loner):54545:7074b0d7:
> Function named CheckIfMeterExistsFunction is not registered to FunctionService
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> 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:760)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377)
> at
> org.apache.geode.metrics.MicrometerBinderTest.processorMetricsBinderExists(MicrometerBinderTest.java:152)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10077) wan-copy region command does not prevent callbacks to be executed on the remote site
[ https://issues.apache.org/jira/browse/GEODE-10077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10077: -- Labels: pull-request-available (was: needsTriage pull-request-available) > wan-copy region command does not prevent callbacks to be executed on the > remote site > > > Key: GEODE-10077 > URL: https://issues.apache.org/jira/browse/GEODE-10077 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The wan-copy region command does not always prevent that callbacks are > executed at the remote site for the entries copied. > For example, if the remote site has more than one server and the gateway > receiver that gets the entries copied does not host the primary bucket of the > entry received, it will send the put operation to the server than hosts the > primary bucket and on this server, callbacks will be executed, provoking, for > example, that if a gateway sender is configured for the region, the event > will be sent by that gateway sender in the remote site. > Also, if the remote site has more than one server and the region has at least > one replica (either because it is a replicated region or because it is a > partitioned region with number of replicas greater than 1) then servers in > the remote site that receive an UpdateMessage from the server that received > the copied entry via the gateway receiver, would execute the callbacks, > provoking, like in the above case that if a gateway sender is configured for > the region, the event will be sent by that gateway sender in the remote site. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10187) PutAllGlobalDUnitTest > testputAllGlobalRemoteVM fails to receive expected TimeoutException
[
https://issues.apache.org/jira/browse/GEODE-10187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10187:
--
Labels: (was: needsTriage)
> PutAllGlobalDUnitTest > testputAllGlobalRemoteVM fails to receive expected
> TimeoutException
> ---
>
> Key: GEODE-10187
> URL: https://issues.apache.org/jira/browse/GEODE-10187
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.14.5
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14277444]
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest >
> testputAllGlobalRemoteVM FAILED
> java.lang.AssertionError: async2 failed
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> at
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest.testputAllGlobalRemoteVM(PutAllGlobalDUnitTest.java:215)
> Caused by:
> java.lang.AssertionError: Should have thrown TimeoutException
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.internal.cache.PutAllGlobalDUnitTest$2.run2(PutAllGlobalDUnitTest.java:193)
> 8805 tests completed, 1 failed, 455 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0942/test-results/distributedTest/1648360227/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0942/test-artifacts/1648360227/distributedtestfiles-openjdk11-1.14.5-build.0942.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10155: -- Labels: pull-request-available (was: needsTriage pull-request-available) > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a Geode client executes a server function with a timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10170) CI failure: DistributedSystemBridgeIntegrationTest > testPrepareErrorAbortsBackup
[
https://issues.apache.org/jira/browse/GEODE-10170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10170:
--
Labels: (was: needsTriage)
> CI failure: DistributedSystemBridgeIntegrationTest >
> testPrepareErrorAbortsBackup
> -
>
> Key: GEODE-10170
> URL: https://issues.apache.org/jira/browse/GEODE-10170
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> DistributedSystemBridgeIntegrationTest > testPrepareErrorAbortsBackup FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.RuntimeException
> but was:
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:333)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:307)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:264)
> ...(83 remaining lines not displayed - this can be changed with
> Assertions.setMaxStackTraceElementsDisplayed)
> at
> org.apache.geode.management.internal.beans.DistributedSystemBridgeIntegrationTest.testPrepareErrorAbortsBackup(DistributedSystemBridgeIntegrationTest.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9142) Make disk size for heavy lifters parameterized
[ https://issues.apache.org/jira/browse/GEODE-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517727#comment-17517727 ] ASF subversion and git services commented on GEODE-9142: Commit 73f1fb935ad929a9cf7e46f295569f9c5f336153 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=73f1fb935a ] GEODE-9142: increase heavy-lifter disk to 200GB to match 1.13, 1.14 and develop (cherry picked from commit a84c26c7610a56b6e22039faf6a8858393e4124a) > Make disk size for heavy lifters parameterized > -- > > Key: GEODE-9142 > URL: https://issues.apache.org/jira/browse/GEODE-9142 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > > We're running out of disk space on certain jobs. Make it so we can choose how > much disk to allocate on a per job basis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10169) CI failure: DistributedSystemBridgeIntegrationTest > testSuccessfulBackup
[
https://issues.apache.org/jira/browse/GEODE-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10169:
--
Labels: (was: needsTriage)
> CI failure: DistributedSystemBridgeIntegrationTest > testSuccessfulBackup
> -
>
> Key: GEODE-10169
> URL: https://issues.apache.org/jira/browse/GEODE-10169
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> DistributedSystemBridgeIntegrationTest > testSuccessfulBackup FAILED
> 17:57:56java.lang.ExceptionInInitializerError
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2526)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2266)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1166)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap.expungeStaleEntries(WeakConcurrentMap.java:139)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap$WithInlinedExpunction.containsKey(WeakConcurrentMap.java:272)
> 17:57:56at
> org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMock(MockMethodAdvice.java:169)
> 17:57:56at
> org.mockito.internal.creation.bytebuddy.MockMethodAdvice.isMocked(MockMethodAdvice.java:174)
> 17:57:56at java.util.Properties.getProperty(Properties.java:969)
> 17:57:56at java.lang.System.getProperty(System.java:722)
> 17:57:56at java.lang.Long.getLong(Long.java:1208)
> 17:57:56at java.lang.Long.getLong(Long.java:1157)
> 17:57:56at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.(StoppableCountDownLatch.java:36)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:333)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:307)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:264)
> 17:57:56at
> org.apache.geode.distributed.internal.ReplyProcessor21.(ReplyProcessor21.java:249)
> 17:57:56at
> org.apache.geode.internal.admin.remote.AdminMultipleReplyProcessor.(AdminMultipleReplyProcessor.java:32)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest$MissingPersistentIDProcessor.(MissingPersistentIDsRequest.java:115)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest$MissingPersistentIDProcessor.(MissingPersistentIDsRequest.java:108)
> 17:57:56at
> org.apache.geode.internal.admin.remote.MissingPersistentIDsRequest.send(MissingPersistentIDsRequest.java:55)
> 17:57:56at
> org.apache.geode.admin.internal.AdminDistributedSystemImpl.getMissingPersistentMembers(AdminDistributedSystemImpl.java:2226)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation$DefaultMissingPersistentMembersProvider.getMissingPersistentMembers(BackupOperation.java:147)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.performBackupUnderLock(BackupOperation.java:89)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.performBackup(BackupOperation.java:77)
> 17:57:56at
> org.apache.geode.internal.cache.backup.BackupOperation.backupAllMembers(BackupOperation.java:71)
> 17:57:56at
> org.apache.geode.management.internal.beans.DistributedSystemBridge.backupAllMembers(DistributedSystemBridge.java:489)
> 17:57:56at
> org.apache.geode.management.internal.beans.DistributedSystemBridgeIntegrationTest.testSuccessfulBackup(DistributedSystemBridgeIntegrationTest.java:113)
> 17:57:56
> 17:57:56Caused by:
> 17:57:56java.lang.NullPointerException
> 17:57:56at
> java.util.concurrent.ThreadLocalRandom.getProbe(ThreadLocalRandom.java:980)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.fullAddCount(ConcurrentHashMap.java:2526)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2266)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1166)
> 17:57:56at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap.expungeStaleEntries(WeakConcurrentMap.java:139)
> 17:57:56at
> org.mockito.internal.util.concurrent.WeakConcurrentMap$WithInlinedExpunction.containsKey(WeakConcurrentMap.java:272)
> 17:57:56at
>
[jira] [Updated] (GEODE-10168) CI failure: RestAPICompatibilityTest > restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible
[
https://issues.apache.org/jira/browse/GEODE-10168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10168:
--
Labels: (was: needsTriage)
> CI failure: RestAPICompatibilityTest >
> restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible
>
>
> Key: GEODE-10168
> URL: https://issues.apache.org/jira/browse/GEODE-10168
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> RestAPICompatibilityTest >
> restCommandExecutedOnLatestLocatorShouldBeBackwardsCompatible[1.13.0] FAILED
> 13:12:20java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 13:12:20Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 13:12:20
> ---
> 13:12:20Found suspect string in 'dunit_suspect-vm1.log' at line 511
> 13:12:20
> 13:12:20[fatal 2022/03/24 20:11:53.071 UTC receiver,heavy-lifter-8ca77d83-23cd-5773-ab23-a0729142416f-17781> tid=55]
> Membership service failure: Member isn't responding to heartbeat requests
> 13:12:20
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:2012)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1085)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:688)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1331)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1267)
> 13:12:20 at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> 13:12:20 at org.jgroups.JChannel.up(JChannel.java:741)
> 13:12:20 at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 13:12:20 at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 13:12:20 at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> 13:12:20 at
> org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> 13:12:20 at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> 13:12:20 at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> 13:12:20 at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> 13:12:20 at
> org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> 13:12:20 at
> org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> 13:12:20 at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> 13:12:20 at org.jgroups.protocols.TP.receive(TP.java:1714)
> 13:12:20 at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> 13:12:20 at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 13:12:20 at java.base/java.lang.Thread.run(Thread.java:829)
> 13:12:20at org.junit.Assert.fail(Assert.java:89)
> 13:12:20at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 13:12:20at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> 13:12:20at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> 13:12:20at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> 13:12:20at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:12:20at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 13:12:20at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 13:12:20at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 13:12:20at
>
[jira] [Updated] (GEODE-10167) CI failure: RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
[
https://issues.apache.org/jira/browse/GEODE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10167:
--
Labels: (was: needsTriage)
> CI failure:
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> ---
>
> Key: GEODE-10167
> URL: https://issues.apache.org/jira/browse/GEODE-10167
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> >
> luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled[from_v1.8.0,
> with reindex=false, singleHopEnabled=true] FAILED
> 00:24:01org.gradle.internal.exceptions.DefaultMultiCauseException:
> Multiple Failures (2 failures)
> 00:24:01 org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase$$Lambda$422/0x000100379c40.run
> in VM 2 running on Host
> heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9.c.apachegeode-ci.internal
> with 4 VMs
> 00:24:01 java.lang.AssertionError: Suspicious strings were written to
> the log during this run.
> 00:24:01Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:24:01
> ---
> 00:24:01Found suspect string in 'dunit_suspect-vm2.log' at line 3243
> 00:24:01
> 00:24:01[fatal 2022/03/25 07:23:55.137 UTC receiver,heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9-23002> tid=49]
> Membership service failure: Member isn't responding to heartbeat requests
> 00:24:01
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> 00:24:01 at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> 00:24:01 at org.jgroups.JChannel.up(JChannel.java:741)
> 00:24:01 at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 00:24:01 at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 00:24:01 at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> 00:24:01 at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> 00:24:01 at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> 00:24:01 at
> org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> 00:24:01 at
> org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> 00:24:01 at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> 00:24:01 at org.jgroups.protocols.TP.receive(TP.java:1714)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> 00:24:01 at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 00:24:01 at java.base/java.lang.Thread.run(Thread.java:829)
> 00:24:01at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> 00:24:01at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> 00:24:01at
>
[jira] [Updated] (GEODE-10176) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10176:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> ---
>
> Key: GEODE-10176
> URL: https://issues.apache.org/jira/browse/GEODE-10176
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:54org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:54Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:54at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:54at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:54at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:225)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10177) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
[
https://issues.apache.org/jira/browse/GEODE-10177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10177:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
>
>
> Key: GEODE-10177
> URL: https://issues.apache.org/jira/browse/GEODE-10177
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers
> FAILED
> 15:35:00org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest that uses
> java.util.concurrent.Future null within 5 minutes.
> 15:35:00at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 15:35:00at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 15:35:00at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 15:35:00at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 15:35:00at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 15:35:00at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownGracefully_givenTwoSubscribersTwoPublishers(PubSubDUnitTest.java:319)
> 15:35:00
> 15:35:00Caused by:
> 15:35:00java.util.concurrent.TimeoutException
> 15:35:00at
> java.util.concurrent.FutureTask.get(FutureTask.java:205)
> 15:35:00at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101)
> 15:35:00at
> org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81)
> 15:35:00at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:101)
> 15:35:00... 5 more {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10175) CI Failure: PubSubDUnitTest > shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
[
https://issues.apache.org/jira/browse/GEODE-10175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10175:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> -
>
> Key: GEODE-10175
> URL: https://issues.apache.org/jira/browse/GEODE-10175
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher
> FAILED
> 15:29:24org.junit.ComparisonFailure: [channel subscription was not
> received]
> 15:29:24Expecting value to be true but was false expected:<[tru]e> but
> was:<[fals]e>
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 15:29:24at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 15:29:24at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 15:29:24at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.shouldContinueToFunction_whenOneServerShutsDownAbruptly_givenTwoSubscribersOnePublisher(PubSubDUnitTest.java:255)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-results/distributedTest/1648080229/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0938/test-artifacts/1648080229/distributedtestfiles-openjdk8-1.14.5-build.0938.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9664) Two different clients with the same durable id will both connect to the servers and receive messages
[
https://issues.apache.org/jira/browse/GEODE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9664:
-
Labels: (was: needsTriage)
> Two different clients with the same durable id will both connect to the
> servers and receive messages
>
>
> Key: GEODE-9664
> URL: https://issues.apache.org/jira/browse/GEODE-9664
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Barrett Oglesby
>Priority: Major
>
> There are two cases:
> # The number of queues is the same as the number of servers (e.g. client
> with subscription-redundancy=1 and 2 servers)
> # The number of queues is less than the number of servers (e.g. client with
> subscription-redundancy=0 and 2 servers)
> h2. Case 1
> In this case, the client first attempts to connect to the primary and fails.
> {noformat}
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.209 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=false
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] The requested durable client has the same identifier (
> client-a ) as an existing durable client (
> CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61581; primary=true; version=GEODE 1.15.0] ). Duplicate
> durable clients are not allowed.
> [warn 2021/10/01 14:37:56.210 PDT server-1 Thread 1> tid=0x4b] CacheClientNotifier: Unsuccessfully registered client
> with identifier
> identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]) and response code 64
> {noformat}
> It then attempts to connect to the secondary and succeeds.
> {noformat}
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal about to
> register
> clientProxyMembershipID=identity(127.0.0.1(client-a-2:89832:loner):61596:fad3ca3d:client-a-2,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300])
> [warn 2021/10/01 14:37:56.215 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=false; version=GEODE 1.15.0]
> [warn 2021/10/01 14:37:56.216 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal existing
> proxy isPaused=true
> [warn 2021/10/01 14:37:56.217 PDT server-2 Thread 1> tid=0x47] XXX CacheClientNotifier.registerClientInternal
> reinitialized existing
> proxy=CacheClientProxy[identity(127.0.0.1(client-a-1:89806:loner):61573:10a9ca3d:client-a-1,connection=2,durableAttributes=DurableClientAttributes[id=client-a;
> timeout=300]); port=61578; primary=true; version=GEODE 1.15.0]
> {noformat}
> The previous secondary is reinitialized and made into a primary. Both queues
> will dispatch events.
> The CacheClientNotifier.registerClientInternal method invoked when a client
> connects does:
> {noformat}
> if (cacheClientProxy.isPaused()) {
> ...
> cacheClientProxy.reinitialize(...);
> } else {
> unsuccessfulMsg = String.format("The requested durable client has the same
> identifier ( %s ) as an existing durable client...);
> logger.warn(unsuccessfulMsg);
> }
> {noformat}
> The CacheClientProxy is paused when the durable client it represents has
> disconnected. Unfortunately, a secondary CacheClientProxy is also paused. So,
> this check is not good enough to prevent a duplicate durable client from
> connecting.
> There are a few things that can also be checked. One of them is:
> {noformat}
> cacheClientProxy.getCommBuffer() == null
> {noformat}
> With that check added, when the client attempts to connect to the secondary,
> it fails just like the it does with the primary.
> The client then exits with this exception:
[jira] [Updated] (GEODE-10174) CI Failure: PubSubDUnitTest > testConcurrentPubSub
[
https://issues.apache.org/jira/browse/GEODE-10174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10174:
--
Labels: redis-triage (was: needsTriage)
> CI Failure: PubSubDUnitTest > testConcurrentPubSub
> --
>
> Key: GEODE-10174
> URL: https://issues.apache.org/jira/browse/GEODE-10174
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: redis-triage
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest >
> testConcurrentPubSub FAILED
> 15:28:39java.util.concurrent.ExecutionException:
> redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> 15:28:39
> 15:28:39Caused by:
> 15:28:39redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:205)
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.readByte(RedisInputStream.java:43)
> 15:28:39at redis.clients.jedis.Protocol.process(Protocol.java:155)
> 15:28:39at redis.clients.jedis.Protocol.read(Protocol.java:220)
> 15:28:39at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:283)
> 15:28:39at
> redis.clients.jedis.Connection.getIntegerReply(Connection.java:225)
> 15:28:39at redis.clients.jedis.Jedis.publish(Jedis.java:2908)
> 15:28:39at
> org.apache.geode.redis.internal.executor.pubsub.PubSubDUnitTest.lambda$testConcurrentPubSub$16(PubSubDUnitTest.java:373)
> 15:28:39
> 15:28:39Caused by:
> 15:28:39java.net.SocketTimeoutException: Read timed out
> 15:28:39at java.net.SocketInputStream.socketRead0(Native
> Method)
> 15:28:39at
> java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:171)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:141)
> 15:28:39at
> java.net.SocketInputStream.read(SocketInputStream.java:127)
> 15:28:39at
> redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:199)
> 15:28:39... 7 more
> 15:29:24 {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9744) bug like CVE-2020-8908
[ https://issues.apache.org/jira/browse/GEODE-9744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9744: - Labels: pull-request-available (was: needsTriage pull-request-available) > bug like CVE-2020-8908 > -- > > Key: GEODE-9744 > URL: https://issues.apache.org/jira/browse/GEODE-9744 > Project: Geode > Issue Type: Bug >Reporter: lujie >Priority: Major > Labels: pull-request-available > > see [https://www.cvedetails.com/cve/CVE-2020-8908/] > A temp directory creation vulnerability exists in all versions of Guava, > allowing an attacker with access to the machine to potentially access data in > a temporary directory created by the Guava API > com.google.common.io.Files.createTempDir(). By default, on unix-like systems, > the created directory is world-readable (readable by an attacker with access > to the system). The method in question has been marked > [@deprecated|https://github.com/deprecated] in versions 30.0 and later and > should not be used. For Android developers, we recommend choosing a temporary > directory API provided by Android, such as context.getCacheDir(). For other > Java developers, we recommend migrating to the Java 7 API > java.nio.file.Files.createTempDirectory() which explicitly configures > permissions of 700, or configuring the Java runtime's java.io.tmpdir system > property to point to a location whose permissions are appropriately > configured. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10081) Freeze during launch of locator
[ https://issues.apache.org/jira/browse/GEODE-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10081: -- Labels: (was: needsTriage) > Freeze during launch of locator > --- > > Key: GEODE-10081 > URL: https://issues.apache.org/jira/browse/GEODE-10081 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.14.2 >Reporter: Julien Gilles >Priority: Major > Attachments: jstackout.txt > > > We are using gfsh with a script to automatically launch a locator and a > server. > During the launch of the locator, the process gfsh just freezes randomly. The > locator process is forked, but gfsh remains frozen. > A jstack on the process shows that the process is stuck on an internal > NativeLibrary.load call. This one happens when gfsh try to attach to the > process : internally the jvm loads the libattach.so library, but the call > never return. > To be complete, Geode is here deployed inside a docker container, using ubi8 > as base image, java is jdk11.0.11 - we have tested with 11.0.13, same issue. > > The stack is the following (full jstack dump attached) > "main" #1 prio=5 os_prio=0 cpu=2402.78ms elapsed=1924.45s allocated=236M > defined_classes=10346 tid=0x7fc904024000 nid=0x16 runnable > [0x7fc90a84a000] > java.lang.Thread.State: RUNNABLE > at java.lang.ClassLoader$NativeLibrary.load0(java.base@11.0.11/Native > Method) > at java.lang.ClassLoader$NativeLibrary.load(java.base@11.0.11/Unknown > Source) > at > java.lang.ClassLoader$NativeLibrary.loadLibrary(java.base@11.0.11/Unknown > Source) > - locked <0x823efe60> (a java.util.HashSet) > at java.lang.ClassLoader.loadLibrary0(java.base@11.0.11/Unknown Source) > at java.lang.ClassLoader.loadLibrary(java.base@11.0.11/Unknown Source) > at java.lang.Runtime.loadLibrary0(java.base@11.0.11/Unknown Source) > - locked <0x828224b8> (a java.lang.Runtime) > at java.lang.System.loadLibrary(java.base@11.0.11/Unknown Source) > at > sun.tools.attach.VirtualMachineImpl.(jdk.attach@11.0.11/Unknown > Source) > at > sun.tools.attach.AttachProviderImpl.attachVirtualMachine(jdk.attach@11.0.11/Unknown > Source) > at com.sun.tools.attach.VirtualMachine.attach(jdk.attach@11.0.11/Unknown > Source) > at > org.apache.geode.internal.process.MBeanProcessController.getJMXServiceURL(MBeanProcessController.java:227) > at > org.apache.geode.internal.process.MBeanProcessController.connect(MBeanProcessController.java:192) > at > org.apache.geode.internal.process.MBeanProcessController.invokeOperationOnTargetMBean(MBeanProcessController.java:159) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:136) > at > org.apache.geode.internal.process.MBeanProcessController.status(MBeanProcessController.java:81) > at > org.apache.geode.internal.process.MBeanOrFileProcessController.status(MBeanOrFileProcessController.java:37) > at > org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:1012) > at > org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:940) > at > org.apache.geode.distributed.LocatorLauncher$LocatorState.fromDirectory(LocatorLauncher.java:2077) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.doStartLocator(StartLocatorCommand.java:267) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.startLocator(StartLocatorCommand.java:133) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.11/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.11/Unknown > Source) > at java.lang.reflect.Method.invoke(java.base@11.0.11/Unknown Source) > at > org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:139) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:149) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10003) Support JDK 17 on Geode
[ https://issues.apache.org/jira/browse/GEODE-10003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10003: -- Labels: jdk17 (was: ) > Support JDK 17 on Geode > --- > > Key: GEODE-10003 > URL: https://issues.apache.org/jira/browse/GEODE-10003 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Priority: Major > Labels: jdk17 > > JDK 17 Schedule: [https://openjdk.java.net/projects/jdk/17/] > The first ticket to suggest going beyond JDK8 was GEODE-3. Now that JDK17 is > LTS, and Spring and other users are embracing JDK17, Geode should at least > run (if not compile) on JDK17. > This may take a lot of work, possibly requiring a new major release. Please > add subtasks to this ticket as necessary. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10036:
--
Labels: jdk17 (was: needsTriage)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: jdk17
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10037) Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the non-internal, public API
[ https://issues.apache.org/jira/browse/GEODE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10037: -- Labels: (was: needsTriage) > Make o.a.geode.internal.cache.wan.spi.WANFactory SPI part of the > non-internal, public API > - > > Key: GEODE-10037 > URL: https://issues.apache.org/jira/browse/GEODE-10037 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.3 >Reporter: John Blum >Priority: Minor > > For the same reasons that were stated in GEODE-10007. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-10115:
--
Labels: (was: needsTriage)
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Reporter: Lynn Gallinat
>Priority: Major
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10132) org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest Failed
[ https://issues.apache.org/jira/browse/GEODE-10132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10132: -- Labels: (was: needsTriage) > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest > Failed > - > > Key: GEODE-10132 > URL: https://issues.apache.org/jira/browse/GEODE-10132 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > > cannotStopServerByNameWhenNotConnected > org.opentest4j.AssertionFailedError: [Exit value from process started by > [fcdfe561432081bf: gfsh -e start locator --name=locator -e start server > --name=server --server-port=0]] > expected: 0 > but was: 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129) > at > org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32) > 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.RunBefores.invokeMethod(RunBefores.java:33) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > 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$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) > at > org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) > at > org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67) > at > org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52) > at > org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96) > at > org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75) > at >
[jira] [Updated] (GEODE-10143) ClusterStartupRule.withLogFile does not seem to work as described in comment
[ https://issues.apache.org/jira/browse/GEODE-10143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10143: -- Labels: GeodeOperationAPI (was: GeodeOperationAPI needsTriage) > ClusterStartupRule.withLogFile does not seem to work as described in comment > > > Key: GEODE-10143 > URL: https://issues.apache.org/jira/browse/GEODE-10143 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.14.4 >Reporter: Joris Melchior >Priority: Minor > Labels: GeodeOperationAPI > > ClusterStartupRule.withLogFile method comment describes that using the flag > will redirect output from standard out to log files. When used this does not > seem to be the case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10156) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-10156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10156: -- Labels: (was: needsTriage) > RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.12.0] > FAILED > - > > Key: GEODE-10156 > URL: https://issues.apache.org/jira/browse/GEODE-10156 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Eric Shu >Priority: Major > > org.opentest4j.AssertionFailedError: [Exit value from process started by > [4f44cb7de3b710f1: gfsh -e start locator --name=loc1 --port=20846 > --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20847 -e start locator > --name=loc2 --port=20848 --http-service-port=0 --locators=localhost[20846] > --J=-Dgemfire.jmx-manager-port=20849 -e start server --name=server1 > --server-port=20850 --locators=localhost[20846] -e start server > --name=server2 --server-port=20851 --locators=localhost[20846] -e deploy > --dir=/tmp/junit4947263696282150978/junit6257623670577599443]] > expected: 0 > but was: 1 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154) > at > org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163) > at > org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153) > at > org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:93) > 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.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at > org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42) > at > org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80) > at >
[jira] [Updated] (GEODE-9789) CI Failure: ConnectCommandWithSSLMultiKeyTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9789:
-
Labels: (was: needsTriage)
> CI Failure: ConnectCommandWithSSLMultiKeyTest > classMethod FAILED
> --
>
> Key: GEODE-9789
> URL: https://issues.apache.org/jira/browse/GEODE-9789
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Jens Deppe
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/windows-gfsh-distributed-test-openjdk8/builds/49
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLMultiKeyTest
> > classMethod FAILED
> 19:03:00org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 0
> running on Host
> heavy-lifter-b81c90cf-1834-5764-b07d-52bb4df9d090.c.apachegeode-ci.internal
> with 4 VMs
> 19:03:00at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 19:03:00at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> 19:03:00at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:225)
> 19:03:00at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:218)
> 19:03:00at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLMultiKeyTest.beforeClass(ConnectCommandWithSSLMultiKeyTest.java:80)
> 19:03:00
> 19:03:00Caused by:
> 19:03:00org.apache.geode.GemFireConfigException: Unable to join the
> distributed system. Operation either timed out, was stopped or Locator does
> not exist. {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0297/test-results/distributedTest/1635475233/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0297/test-artifacts/1635475233/windows-gfshdistributedtest-openjdk8-1.12.6-build.0297.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9989) add a few info level logs in PersistenceAdvisorImpl to identify splitbrain issue
[
https://issues.apache.org/jira/browse/GEODE-9989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9989:
-
Labels: (was: needsTriage)
> add a few info level logs in PersistenceAdvisorImpl to identify splitbrain
> issue
>
>
> Key: GEODE-9989
> URL: https://issues.apache.org/jira/browse/GEODE-9989
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
>
> In scenario like:
> {code:java}
> 03:33:03.644 dataStoregemfire4_4494 recovered from disk
> 03:33:03.732 dataStoregemfire4_4494 closing
> 03:33:03.735 dataStoregemfire4_4494 Initialization of region replicate_5
> completed, send newId(let’s name it 4494) to gemfire2
> 03:33:03.754 dataStoregemfire2_4493 recovered from disk
> 03:33:03.770 dataStoregemfire2_4493 closing
> 03:33:03.792 dataStoregemfire2_4493 Initialization of region replicate_5
> completed. send newId(let’s name is 4493) to gemfire4, but gemfire4 is
> offline. So gemfire4 does not know gemfire2’s newId 4493.
> 03:34:11.247 gemfire4_9779 restarted, it does not know 4493
> 03:34:11.269 gemfire2_9856 restarted, it sends oldId=4493, newId=9856 to
> gemfire4, but gemfire4 does not know either of gemfire2’s oldId and newId
> When gemfire2_9856 asked gemfire4_9779 for its state, gemfire4_9779 replied
> "I don't know you", then gemfire2_9856's starting ends with
> ConflictingPersistentDataException.
> {code}
> We need more log to identify the issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9777) CI failure: QueryConfigurationServiceConstraintsDistributedTest queriesInFlightExecutedByClientsShouldNotBeAffectedWhenMethodAuthorizerIsChanged(RegionType:PARTITION) FAI
[ https://issues.apache.org/jira/browse/GEODE-9777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9777: - Labels: (was: needsTriage) > CI failure: QueryConfigurationServiceConstraintsDistributedTest > queriesInFlightExecutedByClientsShouldNotBeAffectedWhenMethodAuthorizerIsChanged(RegionType:PARTITION) > FAILED > - > > Key: GEODE-9777 > URL: https://issues.apache.org/jira/browse/GEODE-9777 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > > cause of the failure was: AuthenticationRequiredException: Failed to find the > authenticated user -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest fails due to PoolImpl.getRedundantNames() not returning expected servers
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9785:
-
Labels: (was: needsTriage)
> CI Failure: RedundancyLevelPart2DUnitTest fails due to
> PoolImpl.getRedundantNames() not returning expected servers
> --
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> 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.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.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: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
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Resolved] (GEODE-10053) Prevent reading property files every time SSL config is created
[ https://issues.apache.org/jira/browse/GEODE-10053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-10053. - Fix Version/s: 1.15.0 Resolution: Fixed > Prevent reading property files every time SSL config is created > --- > > Key: GEODE-10053 > URL: https://issues.apache.org/jira/browse/GEODE-10053 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > Situation: > 1. Currently, when we create a new SSL config, we read the properties stored > in the LocatorLauncher class. > 2. Using these properties, the DistributionConfigImpl is created which is > used to create the SSLConfig > > Problem: > # While creating the DistributionConfig from properties, it reads the > properties file and security files and creates a new class everytime. > # This is a bit inefficient as the DistributedConfigImpl is already stored > in the InternalLocator. > > Solution: > Use InternalLocator's DistributedConfigurationImpl. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10053) Prevent reading property files every time SSL config is created
[ https://issues.apache.org/jira/browse/GEODE-10053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517720#comment-17517720 ] ASF subversion and git services commented on GEODE-10053: - Commit c2467363452aa73619778a28e4989c62ad482c51 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c246736345 ] GEODE-10053: Use stored DistributionConfig to create SSL configurations (#7366) * While creating SSLConfig no new DistributionConfigImpl is created. * Now, the DistributionConfig is taken from the InternalLocator class. > Prevent reading property files every time SSL config is created > --- > > Key: GEODE-10053 > URL: https://issues.apache.org/jira/browse/GEODE-10053 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > > Situation: > 1. Currently, when we create a new SSL config, we read the properties stored > in the LocatorLauncher class. > 2. Using these properties, the DistributionConfigImpl is created which is > used to create the SSLConfig > > Problem: > # While creating the DistributionConfig from properties, it reads the > properties file and security files and creates a new class everytime. > # This is a bit inefficient as the DistributedConfigImpl is already stored > in the InternalLocator. > > Solution: > Use InternalLocator's DistributedConfigurationImpl. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9142) Make disk size for heavy lifters parameterized
[ https://issues.apache.org/jira/browse/GEODE-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517714#comment-17517714 ] ASF subversion and git services commented on GEODE-9142: Commit a84c26c7610a56b6e22039faf6a8858393e4124a in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a84c26c761 ] GEODE-9142: increase heavy-lifter disk to 200GB to match 1.14 and develop > Make disk size for heavy lifters parameterized > -- > > Key: GEODE-9142 > URL: https://issues.apache.org/jira/browse/GEODE-9142 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > > We're running out of disk space on certain jobs. Make it so we can choose how > much disk to allocate on a per job basis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10157) Add unit tests for all Delta classes in package org.apache.geode.redis.internal.data
[
https://issues.apache.org/jira/browse/GEODE-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10157:
---
Labels: pull-request-available (was: )
> Add unit tests for all Delta classes in package
> org.apache.geode.redis.internal.data
>
>
> Key: GEODE-10157
> URL: https://issues.apache.org/jira/browse/GEODE-10157
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Ray Ingles
>Priority: Major
> Labels: pull-request-available
>
> Expand on tests in
> {{org.apache.geode.redis.internal.data.DeltaClassesJUnitTest}} for all other
> delta-related classes in this package.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10147) CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception while trying to run ssl benchmarks
[
https://issues.apache.org/jira/browse/GEODE-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517695#comment-17517695
]
Geode Integration commented on GEODE-10147:
---
Seen in [benchmark-radish
#272|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/272].
> CI Failure: [ benchmark-with-ssl ] FAILURE: Build failed with an exception
> while trying to run ssl benchmarks
> --
>
> Key: GEODE-10147
> URL: https://issues.apache.org/jira/browse/GEODE-10147
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
>
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> P2pPartitionedPutBenchmark > run() FAILED
> net.schmizz.sshj.transport.TransportException: Connection reset
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.copyFromNode(SshInfrastructure.java:185)
> at
> org.apache.geode.perftest.jvms.RemoteJVMs.copyResults(RemoteJVMs.java:87)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:112)
> at
> org.apache.geode.perftest.runner.DefaultTestRunner.runTest(DefaultTestRunner.java:65)
> at
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark.run(P2pPartitionedPutBenchmark.java:52)
> Caused by:
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:186)
> at java.net.SocketInputStream.read(SocketInputStream.java:140)
> at java.net.SocketInputStream.read(SocketInputStream.java:200)
> at
> net.schmizz.sshj.transport.TransportImpl.receiveServerIdent(TransportImpl.java:211)
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:187)
> ... 8 more
> 4 tests completed, 1 failed
> This is ITERATION 2 of benchmarking against baseline.
> > Task :geode-benchmarks:benchmark
> ReplicatedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1728)
> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by:
> java.io.UncheckedIOException:
> net.schmizz.sshj.transport.TransportException: Server closed connection
> during identification exchange
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:176)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
> ... 6 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
> at
> net.schmizz.sshj.transport.TransportImpl.init(TransportImpl.java:194)
> at net.schmizz.sshj.SSHClient.onConnect(SSHClient.java:793)
> at
> net.schmizz.sshj.SocketClient.connect(SocketClient.java:178)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.getSSHClient(SshInfrastructure.java:74)
> at
> org.apache.geode.perftest.infrastructure.ssh.SshInfrastructure.lambda$copyToNodes$1(SshInfrastructure.java:158)
> ... 7 more
> Caused by:
> net.schmizz.sshj.transport.TransportException: Server closed
> connection during identification exchange
>
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Description:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0,
Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and major
topics is Observability (Metrics and Monitoring, with Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
was:
As part of the ongoing story and themes in Spring Framework 6, Spring Data 3.0,
Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and major
topics is Observability (Monitoring with Metrics, Tracing, and so on).
As part of that effort, Micrometer is undergoing a major revision change from
1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode no
longer runs (or even will build) with Micrometer 2.0.
Either Micrometer should be upgraded to 2.0 (most likely in the next major
version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
perhaps only enabled when Micrometer is on the classpath.
Still a cleaner separation is needed if [Spring] Apache Geode users require and
use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
Micrometer 1.x (currently
[1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
in Apache Geode {{1.14.3}}).
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Metrics and Monitoring, with Tracing, and so
> on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517691#comment-17517691
]
Geode Integration commented on GEODE-10217:
---
Seen in [unit-test-openjdk8
#269|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/unit-test-openjdk8/builds/269]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1069/test-results/test/1649179431/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1069/test-artifacts/1649179431/unittestfiles-openjdk8-1.15.0-build.1069.tgz].
> Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
> -
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
> Byte Buddy could not instrument all classes within the mock's type hierarchy.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
>
[jira] [Updated] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10217:
--
Labels: needsTriage (was: )
> Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
> -
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
> Byte Buddy could not instrument all classes within the mock's type hierarchy.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
> 10:19:40
[jira] [Created] (GEODE-10217) Mockito Unable to Mock org.apache.geode.internal.cache.DiskRegion
Patrick Johnsn created GEODE-10217:
--
Summary: Mockito Unable to Mock
org.apache.geode.internal.cache.DiskRegion
Key: GEODE-10217
URL: https://issues.apache.org/jira/browse/GEODE-10217
Project: Geode
Issue Type: Bug
Components: core, tests
Reporter: Patrick Johnsn
Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
Byte Buddy could not instrument all classes within the mock's type hierarchy.
{noformat}
DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
10:19:40org.mockito.exceptions.base.MockitoException:
10:19:40Mockito cannot mock this class: class
org.apache.geode.internal.cache.DiskRegion.
10:19:40
10:19:40If you're not sure why you're getting this error, please report to
the mailing list.
10:19:40
10:19:40
10:19:40Java : 1.8
10:19:40JVM vendor name: BellSoft
10:19:40JVM vendor version : 25.322-b06
10:19:40JVM name : OpenJDK 64-Bit Server VM
10:19:40JVM version: 1.8.0_322-b06
10:19:40JVM info : mixed mode
10:19:40OS name: Linux
10:19:40OS version : 5.4.0-1069-gcp
10:19:40
10:19:40
10:19:40You are seeing this disclaimer because Mockito is configured to
create inlined mocks.
10:19:40You can learn about inline mocks and their limitations under item
#39 of the Mockito class javadoc.
10:19:40
10:19:40Underlying exception :
org.mockito.exceptions.base.MockitoException: Could not modify all classes
[class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at
org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
10:19:40
10:19:40Caused by:
10:19:40org.mockito.exceptions.base.MockitoException: Could not modify
all classes [class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.IllegalStateException:
10:19:40Byte Buddy could not instrument all classes within the
mock's type hierarchy
10:19:40
10:19:40This problem should never occur for javac-compiled classes.
This problem has been observed for classes that are:
10:19:40 - Compiled by older versions of scalac
10:19:40 - Classes that are part of the Android distribution
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
10:19:40at
org.mockito.internal.util.MockUtil.createMock(MockUtil.java:53)
10:19:40at
org.mockito.internal.MockitoCore.mock(MockitoCore.java:96)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1965)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1880)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517690#comment-17517690
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#260|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/260].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 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.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-10045:
--
Priority: Blocker (was: Major)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10065) Fix regexp in gnmsg for handshake messages
[ https://issues.apache.org/jira/browse/GEODE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10065: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Fix regexp in gnmsg for handshake messages > -- > > Key: GEODE-10065 > URL: https://issues.apache.org/jira/browse/GEODE-10065 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > gnmsg tool has a bug in the regexp for handshake messages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10065) Fix regexp in gnmsg for handshake messages
[ https://issues.apache.org/jira/browse/GEODE-10065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-10065: -- Component/s: native client > Fix regexp in gnmsg for handshake messages > -- > > Key: GEODE-10065 > URL: https://issues.apache.org/jira/browse/GEODE-10065 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: needsTriage, pull-request-available > > gnmsg tool has a bug in the regexp for handshake messages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9804: - Labels: pull-request-available (was: needsTriage pull-request-available) > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9804: - Component/s: native client > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9711) Fix the typos in ConflationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-9711: - Labels: pull-request-available (was: needsTriage pull-request-available) > Fix the typos in ConflationDUnitTestHelper > -- > > Key: GEODE-9711 > URL: https://issues.apache.org/jira/browse/GEODE-9711 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10198) LINSERT is case-sensitive for arguments
[ https://issues.apache.org/jira/browse/GEODE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Tripura Sundari Kaza Venkata resolved GEODE-10198. --- Fix Version/s: 1.15.0 Resolution: Fixed > LINSERT is case-sensitive for arguments > --- > > Key: GEODE-10198 > URL: https://issues.apache.org/jira/browse/GEODE-10198 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: pull-request-available, redis-triage > Fix For: 1.15.0 > > > Qualifier arguments for LINSERT (e.g. BEFORE, AFTER) are only recognized if > they are uppercased. Native Redis is not case-sensitive with respect to these > arguments. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-10144: - I am going to revert the revert, so reopening this ticket again: the exception happened on the old client connecting to the new server. Once CQ determined this user is expired, it will wait for 5 seconds for the client to do some operation to refresh the subject, but the implementation of the security manager only throws the AuthExpiredException every 30 seconds, so the client operation never gets that exception therefore the refresh didn't happen. CQ disconnects the client, but the client didn't know that and continues operations, thus it receives this exception. The correct behavior is security manager once determines a user expired, it should throw the auth-expired exception all the time, then if the client choose to send in a refreshed token, then CQ will continue, if the client didn't send in a refreshed token, then client should get AuthenticationFailedException immediately after the 2nd try. > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8617) org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different Geode version due to EOFException
[
https://issues.apache.org/jira/browse/GEODE-8617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517633#comment-17517633
]
Geode Integration commented on GEODE-8617:
--
Seen on support/1.12 in [upgrade-test-openjdk8
#47|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/upgrade-test-openjdk8/builds/47]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0370/test-results/upgradeTest/1649149304/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0370/test-artifacts/1649149304/upgradetestfiles-openjdk8-1.12.10-build.0370.tgz].
> org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different
> Geode version due to EOFException
>
>
> Key: GEODE-8617
> URL: https://issues.apache.org/jira/browse/GEODE-8617
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.11.0, 1.12.0
>Reporter: Donal Evans
>Priority: Major
>
> This failure shows up in RollingUpgrade and BackwardsCompatibility tests
> occasionally when attempting to bounce a VM and restart it with a different
> version of Geode. The initial failure shows up as an {{EOFException}}, but
> subsequent runs of the same test with other versions (as part of the
> RollingUpgrade/BackwardsCompatibility test) fail with {{ConnectException:
> Connection refused (Connection refused)}}.
> Two other tickets (GEODE-7142 and GEODE-6337) exist describing this failure
> in specific RollingUpgrade tests, but as it seems to be more general and not
> related to a specific test, this ticket has been created to consolidate them.
> An example failure from a BackwardsCompatibility test is attached below.
> {noformat}
> > Task :geode-core:upgradeTest
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[9] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$30/1525819532.run in VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.lang.IllegalStateException: VM not available: VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[10] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.VM$$Lambda$29/478086753.call in VM 3 running on
> Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running
> on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested exception is:
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
> in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1
> Caused by:
> java.rmi.ConnectException: Connection refused to host: 172.17.0.49;
> nested
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517626#comment-17517626 ] Geode Integration commented on GEODE-7098: -- Seen on support/1.12 in [distributed-test-openjdk11 #54|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk11/builds/54] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0370/test-results/distributedTest/1649153064/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0370/test-artifacts/1649153064/distributedtestfiles-openjdk11-1.12.10-build.0370.tgz]. > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Affects Versions: 1.11.0 >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: flaky > Fix For: 1.13.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10126. Fix Version/s: 1.15.0 Resolution: Fixed > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10126: -- Assignee: Jens Deppe > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10198) LINSERT is case-sensitive for arguments
[ https://issues.apache.org/jira/browse/GEODE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517623#comment-17517623 ] ASF subversion and git services commented on GEODE-10198: - Commit f1d5a2587754e49f2c7e6f0e1fc39b0221fb8ec3 in geode's branch refs/heads/develop from Bala Kaza Venkata [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f1d5a25877 ] GEODE-10198: Fix LINSERT's case-sensitivity for arguments (#7552) LINSERT was case-sensitive with its arguments BEFORE/AFTER.Redis implementation of LINSERT is not case-sensitive. > LINSERT is case-sensitive for arguments > --- > > Key: GEODE-10198 > URL: https://issues.apache.org/jira/browse/GEODE-10198 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: pull-request-available, redis-triage > > Qualifier arguments for LINSERT (e.g. BEFORE, AFTER) are only recognized if > they are uppercased. Native Redis is not case-sensitive with respect to these > arguments. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10126) Refactor Configuration To Use System Properties
[ https://issues.apache.org/jira/browse/GEODE-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517565#comment-17517565 ] ASF subversion and git services commented on GEODE-10126: - Commit ee1c412d8af3e6311f569948c3248eddc1fe8009 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee1c412d8a ] GEODE-10126: Replace Geode for Redis properties with system properties (#7478) * GEODE-10126: Replace Geode for Redis properties with system properties - All previous Geode for Redis properties that were defined in geode-core are replaced by java system properties. - gemfire.geode-for-redis-port - gemfire.geode-for-redis-bind-address - gemfire.geode-for-redis-bind-username - gemfire.geode-for-redis-redundant-copies - gemfire.geode-for-redis-enabled - Redis is enabled (using defaults) if the `enabled` property is set to true OR if any of the other properties are explicitly set as java system properties. - Introduce `RedisConfiguration` interface to access properties. - Concrete implementation of `SystemPropertyBasedRedisConfiguration` that uses system properties to define Radish properties. - Integration Tests use `TestRedisConfiguration` to avoid having to set system properties. - Services started by Geode (`CacheService`s) that throw exceptions during initialization will cause the Cache to fail to startup. Previously any such errors were only logged. - Default bind address is explicitly 0.0.0.0 which is more expressive than just an empty string > Refactor Configuration To Use System Properties > --- > > Key: GEODE-10126 > URL: https://issues.apache.org/jira/browse/GEODE-10126 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > The properties currently being used by the Redis module are defined in Geode > core. These properties need to be removed from Geode core and refactored to > system properties. > > Validators must also be added for the system properties to ensure that users > provide correct values. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9880:
-
Labels: blocks-1.12.10 blocks-1.15.0 membership (was: blocks-1.12.10
blocks-1.15.0 blocks-1.15.0 membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9880:
-
Labels: blocks-1.12.10 blocks-1.15.0 blocks-1.15.0 membership (was:
blocks-1.12.10 blocks-1.15.0 membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bala Tripura Sundari Kaza Venkata reassigned GEODE-10121:
-
Assignee: Bala Tripura Sundari Kaza Venkata
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Bala Tripura Sundari Kaza Venkata
>Priority: Major
> Labels: pull-request-available, redis-triage
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10198) LINSERT is case-sensitive for arguments
[ https://issues.apache.org/jira/browse/GEODE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bala Tripura Sundari Kaza Venkata reassigned GEODE-10198: - Assignee: Bala Tripura Sundari Kaza Venkata > LINSERT is case-sensitive for arguments > --- > > Key: GEODE-10198 > URL: https://issues.apache.org/jira/browse/GEODE-10198 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: pull-request-available, redis-triage > > Qualifier arguments for LINSERT (e.g. BEFORE, AFTER) are only recognized if > they are uppercased. Native Redis is not case-sensitive with respect to these > arguments. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10198) LINSERT is case-sensitive for arguments
[ https://issues.apache.org/jira/browse/GEODE-10198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10198: --- Labels: pull-request-available redis-triage (was: redis-triage) > LINSERT is case-sensitive for arguments > --- > > Key: GEODE-10198 > URL: https://issues.apache.org/jira/browse/GEODE-10198 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Priority: Major > Labels: pull-request-available, redis-triage > > Qualifier arguments for LINSERT (e.g. BEFORE, AFTER) are only recognized if > they are uppercased. Native Redis is not case-sensitive with respect to these > arguments. -- This message was sent by Atlassian Jira (v8.20.1#820001)
