[jira] [Closed] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10323.
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError:
> expected:<100> but was:<1048576>
>
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10401) Oplog recovery takes too long due to fault in fastutil library
[
https://issues.apache.org/jira/browse/GEODE-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10401.
> Oplog recovery takes too long due to fault in fastutil library
> --
>
> Key: GEODE-10401
> URL: https://issues.apache.org/jira/browse/GEODE-10401
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> {color:#0e101a}As we already know, the .drf file delete operations only
> contain OplogEntryID. During recovery, the server reads (byte by byte) each
> OplogEntryID and stores it in a HashSet to use later when recovering .crf
> files. There are two types of HashSets: IntOpenHashSet and LongOpenHashSet.
> The OplogEntryID of type
> {color}_{color:#0e101a}integer{color}_{color:#0e101a} will be stored in
> IntOpenHashSet, and {color}_{color:#0e101a}long
> integer{color}_{color:#0e101a} in LongOpenHashSet, probably due to memory
> optimization and performance factors. OplogEntryID starts with a zero and
> increments throughout time.
> {color}
> {color:#0e101a}We have observed in logs that between exception (There is a
> large number of deleted entries) and the previous log have passed more than 4
> minutes (sometimes even more).{color}
> {code:java}
> {"timestamp":"2022-06-14T21:41:43.772+08:00","severity":"info","message":"Recovering
> oplog#271 /opt/dbservice/data/datastore/BACKUPdataDiskStore_271.drf for disk
> store dataDiskStore.","metadata":
> {"timestamp":"2022-06-14T21:46:02.152+08:00","severity":"warning","message":"There
> is a large number of deleted entries within the disk-store, please execute
> an offline
> compaction.","metadata":
> {code}
> {color:#0e101a}When the above exception occurs, that means that the limit of
> {color}_{color:#0e101a}805306401{color}_{color:#0e101a} entries in
> IntOpenHashSet has been reached. In that case, the server rolls to the new
> IntOpenHashSet, where an exception and the delay could happen again.{color}
> {color:#0e101a}The problem is that due to the fault in FastUtil dependency
> (IntOpenHashSet and LongOpenHashSet), the unnecessary rehashing happens
> multiple times before the max size is reached. The{color}
> _{color:#0e101a}rehashing starts from{color}_ {color:#0e101a}805306368
> onwards for each new entry until the max size. This rehashing adds several
> minutes to .drf Oplog recovery, but does nothing as max is already
> reached.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser
[ https://issues.apache.org/jira/browse/GEODE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10411. > XSS vulnerabiltiy in Pulse data browser > --- > > Key: GEODE-10411 > URL: https://issues.apache.org/jira/browse/GEODE-10411 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.9, 1.12.10, 1.13.8, 1.13.9, 1.14.4, 1.14.5, 1.15.0, > 1.15.1, 1.16.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.1, 1.16.0 > > > # Description: > Stored XSS via data injection into Geode database, the injected > payload eventually gets executed on Pulse web application when the > admin querying data from Geode. > # PoC: > Step 1: With Geode up and running, run gfsh command to get into > interactive mode: > shell$ gfsh > Step 2: In gfsh console, execute the following command to insert a > data entry into regionA (assume that regionA is created before). Note > that the value of this data entry contains JavaScript code: > gfsh> put --region=regionA --key="test" --value="alert(1)" > Step 3: Open browser to query editor of Pulse web application at > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0 > (assume that already > logged in as admin), execute the following query: > SELECT * FROM /regionA > Step 4: Data from regionA will be retrieved, the XSS payload > eventually get executed > # Why this is an issue? > Developer maybe saves user-controlled data to Geode database, users > maybe submit data via an arbitrary client application (for example, a > web application), the use of gfsh console just simplifies the PoC. > # IMPACT: > Exploiting this XSS vulnerability, an attacker can steal the admin's > session cookie, therefore take over the admin account. > # CVSS: 7.6 HIGH > (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0 > ) > (re-calculate if not correct) > # Fix: > The Pulse web application must URL encode data retrieved from Geode database. > # Credit: > The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10281.
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> {color:#0e101a}It seems that the following PR
> {color}[{color:#4a6ee0}[https://github.com/apache/geode/pull/3044]{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10346) Correct batch-time-interval description in documentation
[ https://issues.apache.org/jira/browse/GEODE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10346. > Correct batch-time-interval description in documentation > > > Key: GEODE-10346 > URL: https://issues.apache.org/jira/browse/GEODE-10346 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > The description of the batch-time-interval parameter for the Gateway Sender > in the Geode documentation states the following: > "Maximum amount of time, in ms, that can elapse before a batch is delivered." > Nevertheless, that is not completely true. > The number of ms that can elapse before a batch is delivered could be longer > than what is configured in batch-time-interval in the case that the batch > being created has not yet reached the value of max-batch-size and there are > still events in the gateway sender's queue to be added to the batch. If that > is the case, new events will keep being added to the batch without taking > into account the value for batch-time-interval. > The batch-time-interval parameter is only used when the batch being filled > has not reached the max-batch-size but there are no events in the queue. In > that case, in order not to delay the delivery of the batch until there are > events in the queue, this value is used to determine if the batch must be > sent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10291) Support Jammy (ubuntu 22.04)
[ https://issues.apache.org/jira/browse/GEODE-10291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10291. > Support Jammy (ubuntu 22.04) > > > Key: GEODE-10291 > URL: https://issues.apache.org/jira/browse/GEODE-10291 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > Native client should compile on the latest (ubuntu 22.04) operating system. > Consider including a new pipeline as part of this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10371) C++ Native client: Improve dispersion on connections expiration
[ https://issues.apache.org/jira/browse/GEODE-10371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10371. > C++ Native client: Improve dispersion on connections expiration > --- > > Key: GEODE-10371 > URL: https://issues.apache.org/jira/browse/GEODE-10371 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > The dispersion on connections expirations in the C++ native client works in > such a way that it adds a dispersion (variance) between -9% and 9% over the > time for a connection to expire due to load-conditioning so that, in the > event of having many connections being created at the same, they do not > expire at the right exact time. > Nevertheless, the current implementation has two problems: > - The randomness of the variance depends on the current time in seconds. As a > result, for connections created in the same second, the variance will be the > same and, therefore, the expiration time too. > - The randomness is created using the C standard's library "rand()" function > which is considered not secure. > It is recommended to change the library used to generate the random variance > to a secure one and also to make sure that for the time in seconds it does > not return the same variance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-9484) Data inconsistency in replicated region with 3 or more servers, and one server is down
[ https://issues.apache.org/jira/browse/GEODE-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9484. --- > Data inconsistency in replicated region with 3 or more servers, and one > server is down > --- > > Key: GEODE-9484 > URL: https://issues.apache.org/jira/browse/GEODE-9484 > Project: Geode > Issue Type: Improvement > Components: client/server, regions >Affects Versions: 1.13.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > We have configured replicated region with 3 or more servers, and client is > configured with read timeout set to value same or smaller than member timeout. > In case while client is putting data in region, one of replicated servers is > shutdown, it is observed that we have data inconsistency. > > We see that data part of data is written in server connected with client, but > in remaining replicated servers it is missing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10420) Handle WAN event when interrupted
[ https://issues.apache.org/jira/browse/GEODE-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10420. > Handle WAN event when interrupted > - > > Key: GEODE-10420 > URL: https://issues.apache.org/jira/browse/GEODE-10420 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.1, 1.16.0 > > > It is possible that an event of which a gateway sender is to be notified is > lost if during the process the thread is interrupted. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10352) Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10352. > Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode > documentation > --- > > Key: GEODE-10352 > URL: https://issues.apache.org/jira/browse/GEODE-10352 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > The script to preview the documentation of Geode (./preview-user-guide.sh) is > not working anymore. > The following error appears while running it (unless you have a previously > downloaded geodedocs/temp docker image in your local docker repo): > ERROR: Error installing elasticsearch: > The last version of faraday (>= 0) to support your Ruby & RubyGems was > 1.10.0. Try installing it with `gem install faraday -v 1.10.0` and then > running the current command again > faraday requires Ruby version >= 2.6. The current ruby version is > 2.5.9.229. > That error prevents the preview script to work. > It is needed to update the docker image used to preview the documentation to > use a Ruby version >= 2.6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10417) Fix NullPointerException when getting events from the gw sender queue to complete transactions
[ https://issues.apache.org/jira/browse/GEODE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10417. > Fix NullPointerException when getting events from the gw sender queue to > complete transactions > -- > > Key: GEODE-10417 > URL: https://issues.apache.org/jira/browse/GEODE-10417 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.1, 1.16.0 > > > When the WAN group-transaction-events feature is enabled in a parallel > gateway sender, it is possible to get a NullPointerException when retrieving > events from the queue to complete a transaction if the event in the queue is > null. > If this situation is reached then the gateway sender dispatcher will not > dispatch queue events anymore and therefore the WAN replication will not > progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10422) Add doc for using parallel recovery disk store
[ https://issues.apache.org/jira/browse/GEODE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10422. > Add doc for using parallel recovery disk store > -- > > Key: GEODE-10422 > URL: https://issues.apache.org/jira/browse/GEODE-10422 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > There are missing part for parallel recovery of disk stores. > It isn't specified that in case the user use the same disk store for the pdx > and the region, disk store recovery will go in the sequential mode. So in > case you want to use parallel disk store recovery it should be different disk > stores for the pdx and the disk store. Otherwise, it will go sequentially, > despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10415.
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10403) Distributed deadlock when stopping gateway sender
[
https://issues.apache.org/jira/browse/GEODE-10403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10403.
> Distributed deadlock when stopping gateway sender
> -
>
> Key: GEODE-10403
> URL: https://issues.apache.org/jira/browse/GEODE-10403
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> A distributed deadlock has been found during some tests of a Geode system
> with WAN replication when stopping the gateway sender while sending a fair
> amount of operations to the servers.
> The distributed deadlock manifests in the gateway sender stop command hanging
> forever and by all normal Geode operations from clients (gets, puts,...) not
> being responded.
> The situation is provoked by the Gateway sender stop command that first takes
> the lifecycle lock and then, at a given point, tries to retrieve the size of
> the gateway sender. This operation, that requires communication with the
> other peers never finishes, probably because the response from one of the
> peers is never received.
> Another thread is blocked when trying to acquire the lifecycle lock in
> AbstractGatewaySender.distribute().
> Finally many threads handling Geode operations (get, put...) get blocked in
> the DistributedCacheOperation._distribute() call waiting for a response from
> another peer.
> Thread dump section from blocked gateway sender stop command in call to get
> size of queue:
> {{"ConcurrentParallelGatewaySenderEventProcessor Stopper Thread1" #1316
> daemon prio=10 os_prio=0 cpu=45.55ms elapsed=4152.76s tid=0x7f92bc1c2000
> nid=0x2154 waiting on condition [0x7f9179cd2000]}}
> {{ java.lang.Thread.State: TIMED_WAITING (parking)}}
> {{ at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)}}
> {{ - parking to wait for <0x00031ca2be50> (a
> java.util.concurrent.CountDownLatch$Sync)}}
> {{ at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)}}
> {{ at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:1079)}}
> {{ at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:1369)}}
> {{ at
> java.util.concurrent.CountDownLatch.await(java.base@11.0.11/CountDownLatch.java:278)}}
> {{ at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)}}
> {{ at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)}}
> {{ at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)}}
> {{ at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)}}
> {{ at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)}}
> {{ at
> org.apache.geode.internal.cache.partitioned.SizeMessage$SizeResponse.waitBucketSizes(SizeMessage.java:344)}}
> {{ at
> org.apache.geode.internal.cache.PartitionedRegion.getSizeRemotely(PartitionedRegion.java:6758)}}
> {{ at
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6709)}}
> {{ at
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6691)}}
> {{ at
> org.apache.geode.internal.cache.PartitionedRegion.getRegionSize(PartitionedRegion.java:6663)}}
> {{ at
> org.apache.geode.internal.cache.LocalRegionDataView.entryCount(LocalRegionDataView.java:99)}}
> {{ at
> org.apache.geode.internal.cache.LocalRegion.entryCount(LocalRegion.java:2078)}}
> {{ at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8301)}}
> {{ at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.size(ParallelGatewaySenderQueue.java:1670)}}
> {{ at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.closeProcessor(AbstractGatewaySenderEventProcessor.java:1259)}}
> {{ at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.stopProcessing(AbstractGatewaySenderEventProcessor.java:1247)}}
> {{ at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor$SenderStopperCallable.call(AbstractGatewaySenderEventProcessor.java:1399)}}
> {{ at
>
[jira] [Closed] (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 ] Owen Nichols closed GEODE-10155. > 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 > Fix For: 1.15.1, 1.16.0 > > > If a Geode client executes a non-HA server function (isHA=false) 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.10#820010)
[jira] [Closed] (GEODE-10404) Fix compilation for Java 11
[
https://issues.apache.org/jira/browse/GEODE-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10404.
> Fix compilation for Java 11
> ---
>
> Key: GEODE-10404
> URL: https://issues.apache.org/jira/browse/GEODE-10404
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> It seems that after merging
> [#973|https://github.com/apache/geode-native/pull/973], compilation with
> Geode Native Docker build image for version 1.15.0 is broken. This is the
> compilation error:
> {noformat}
> tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
> character (0xAC) for encoding US-ASCII
> pdxInstanceFactory.writeString("utfHugeField", longString + "???");
> {noformat}
> As it seems, the latest docker image is using Java 11, which handles UTF-8
> strings in a different way to Java 8, so that's why compilation is working
> with packer images and not with Docker build image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10412) Destroy region command doesn't clear the region related expired tombstones
[
https://issues.apache.org/jira/browse/GEODE-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10412.
> Destroy region command doesn't clear the region related expired tombstones
> --
>
> Key: GEODE-10412
> URL: https://issues.apache.org/jira/browse/GEODE-10412
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> Tombstones in geode are kept on two maps: expiredTombstones and tombstones
> (non-expired ones). When a region is destroyed, it must clear all the related
> expired and non-expired tombstones from memory. Due to the below code bug,
> expired tombstones aren't cleared when non-expired tombstones are available
> during the region destruction:
> {code:java}
> private boolean removeIf(Predicate predicate) {
> return removeUnexpiredIf(predicate) || removeExpiredIf(predicate);
> }
> {code}
> Because of the above, non-expired tombstones are never removed from memory,
> preventing other tombstones from being cleared. Since other tombstones never
> expire, the compaction is not done, and therefore the disk is filled, causing
> the issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10348) Correct documentation about conflation
[ https://issues.apache.org/jira/browse/GEODE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10348. > Correct documentation about conflation > -- > > Key: GEODE-10348 > URL: https://issues.apache.org/jira/browse/GEODE-10348 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > The Geode documentation states on conflation: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message assumes the value of the new update and the new update is dropped, as > shown here for key A." > Nevertheless, that is not correct. The actual behavior is the following: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message is removed and the new update is added to the end of the queue, as > shown here for key A." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602568#comment-17602568
]
Owen Nichols commented on GEODE-10415:
--
Please note _any_ change to jgroups version will break ability to upgrade a
running Geode cluster with no downtime. Might be worth discussing that tradeoff
on the dev list first...it's hard to say whether security or downtime are of
greater importance to all Geode users.
The Spring CVE is not something that can be fixed by upgrading. More details
from the spring team here:
https://github.com/spring-projects/spring-framework/issues/24434#issuecomment-744519525
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Deleted] (GEODE-10397) Meyhomes Capital Phú Quốc Landup
[
https://issues.apache.org/jira/browse/GEODE-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols deleted GEODE-10397:
-
> Meyhomes Capital Phú Quốc Landup
>
>
> Key: GEODE-10397
> URL: https://issues.apache.org/jira/browse/GEODE-10397
> Project: Geode
> Issue Type: Bug
>Reporter: Meyhomes Capital Phú Quốc Landup
>Priority: Major
> Labels: needsTriage
>
> Thông tin mới về dự án Meyhomes Capital Phú Quốc LandUp
> [https://landup.net/du-an/meyhomes-capital-phu-quoc/], vị trí, thanh toán,
> chiết khấu, giá bán...dự án Meyhomes Capital Phú Quốc của chủ đầu tư Tân Á
> Đại Thành. Dự án có vị trí đắc địa ngay gần bờ biển Bãi Trường, được nhiều
> nhà đầu tư quan tâm tìm mua.
> *Website:* ++ [https://landup.net/du-an/meyhomes-capital-phu-quoc/]
> {*}Youtube{*}: [https://www.youtube.com/channel/UCkXw7NGUetiWxAkET5Vc1WA/]
> *Blog:*
> [https://sites.google.com/view/meyhomescapitalpq-landup/|https://sites.google.com/view/meyhomescapitalpq-landup/trang-ch%E1%BB%A7]
> *Email:* meyhomescapitalphuq...@gmail.com
> *Địa chỉ:* 20 Nguyễn Văn Đậu, Phường 5, Quận Phú Nhuận, Thành phố Hồ Chí Minh
> *Số điện thoại:* 0928.0168.69
> *Tags:* Dự án Meyhomes Capital Phú Quốc, Meyhomes Capital Phú Quốc, BĐS Tân Á
> Đại Thành, Bất động sản Phú Quốc, LandUp, Bất động sản
> *Hashtag:* #meyhomescapital #meyhomescapitalphuquoc #batdongsanphuquoc
> #tanadaithanh #batdongsan #landup
> *Xã hội của tôi:*
> [https://www.facebook.com/Meyhomes-Capital-Ph%C3%BA-Qu%E1%BB%91c-112117104876503]
> [https://www.pinterest.com/meyhomescapitalpqlandup|https://www.pinterest.com/meyhomescapitalpqlandup/]
> [https://twitter.com/MeyhomesCapitaI]
> [https://about.me/meyhomescapitalpqlandup]
> [https://www.behance.net/meyhomescapitalpq]
> [https://meyhomescapitalpqlandup.tumblr.com|https://meyhomescapitalpqlandup.tumblr.com/]
> [https://www.tumblr.com/blog/view/meyhomescapitalpqlandup]
> [https://soundcloud.com/meyhomescapitalpq-landup]
> [https://www.instagram.com/meyhomescapitalpglandup|https://www.instagram.com/meyhomescapitalpglandup/]
> [https://myhomescapitalphuquoclandup.wordpress.com/]
> [https://meyhomescapitalpqlandup.weebly.com/]
> [https://github.com/meyhomescapitalpq-landup]
> [https://meyhomescapitalpq-landup.blogspot.com/2022/07/meyhomes-capital-phu-quoc-landup.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Deleted] (GEODE-10399) CI: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest > test[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols deleted GEODE-10399:
-
> CI:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> > test[1.8.0] FAILED
> --
>
> Key: GEODE-10399
> URL: https://issues.apache.org/jira/browse/GEODE-10399
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> It's probably due to environment. Similar to GEODE-9531.
> {code:java}
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> > test[1.8.0] FAILED
> org.opentest4j.AssertionFailedError: [Locator in
> /tmp/junit1239217839732739821/locator on
> heavy-lifter-fbdeb3b6-ac9b-5022-9bde-6fc2316be33d.c.gemfire-dev.internal[10334]
> is currently not responding.
> ]
> expected: OK
> but was: ERROR
> 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.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:108)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.stop(TomcatSessionBackwardsCompatibilityTestBase.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.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
>
[jira] [Resolved] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10089. -- Resolution: Fixed > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > UPDATE: As per [Mar 16 dev list > discussion|https://lists.apache.org/thread/twlwzcvmx2kqw15whpmxkh2h8bmrok21], > support/1.15 was retracted. Work will continue on develop with an eye toward > re-cutting support/1.15 in ~June > UPDATE: support/1.15 was re-cut on May 9 with an eye toward shipping in mid > to late June (2022). > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9038. --- > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm0.log' at line 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10320) bump micrometer to 1.9.0
[ https://issues.apache.org/jira/browse/GEODE-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10320. > bump micrometer to 1.9.0 > > > Key: GEODE-10320 > URL: https://issues.apache.org/jira/browse/GEODE-10320 > Project: Geode > Issue Type: Improvement >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > To remain Spring-friendly and JDK17-optimal, it will help if Geode 1.15.0 can > ship with micrometer 1.9.0 (rather than 1.8.5) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9947) Implement LINDEX
[ https://issues.apache.org/jira/browse/GEODE-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9947. --- > Implement LINDEX > > > Key: GEODE-9947 > URL: https://issues.apache.org/jira/browse/GEODE-9947 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [LINDEX|https://redis.io/commands/lindex] command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9669) AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne is Failing
[ https://issues.apache.org/jira/browse/GEODE-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9669. --- > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > is Failing > > > Key: GEODE-9669 > URL: https://issues.apache.org/jira/browse/GEODE-9669 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > test is currently disabled with the @Ignore annotation. Ideally, we would > like to remove the @Ignore annotation and fix the test/product issues causing > failure. At present, the tests always returns a 1 for the queried stat. > +Acceptance Criteria+ > The > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > test no longer fails and the @Ignore annotation has been removed. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9449) remove 'b' prefix from constants
[ https://issues.apache.org/jira/browse/GEODE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9449. --- > remove 'b' prefix from constants > > > Key: GEODE-9449 > URL: https://issues.apache.org/jira/browse/GEODE-9449 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Kristen >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > I number of constants in the redis packages have a 'b' prefix on their name. > This might have been a use of Hungarian notation but that is not clear. The > convention for constant names in geode is all upper case with underscore > between words. So the 'b' prefix should be removed. See StringBytesGlossary > for the location of many of these constants. Most of the constants in > StringBytesGlossary contains bytes, one or more, but if a few of the > constants in it are actually String instances. Consider renaming them to have > _STRING suffix or moving them to another class like StringGlossary. > The byte array constants in this class are marked with the MakeImmutable > annotation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
[
https://issues.apache.org/jira/browse/GEODE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9666.
---
> Client throws NoAvailableLocatorsException after locators change IP addresses
> -
>
> Key: GEODE-9666
> URL: https://issues.apache.org/jira/browse/GEODE-9666
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> We have a test for Geode on Kubernetes which:
> * Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
> * Deploys 5 Spring boot client Pods which continually do PUTs and GETs
> * Triggers a rolling restart of the locator Pods
> ** The rolling restart operation restarts one locator at a time, waiting for
> each restarted locator to become fully online before restarting the next
> locator
> * Stops the client operations and validates there were no exceptions thrown
> in the clients.
> Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
> clients:
> {code:none}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
>
> system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
> at
> org.apache.geode.kubernetes.client.api.Controller.evaluateRegion(Controller.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:197)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:141)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:894)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
> at
>
[jira] [Closed] (GEODE-9770) CI Failure: ConflictingPersistentDataException in PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict
[
https://issues.apache.org/jira/browse/GEODE-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9770.
---
> CI Failure: ConflictingPersistentDataException in
> PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict
> -
>
> Key: GEODE-9770
> URL: https://issues.apache.org/jira/browse/GEODE-9770
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> This ConflictingPersistentDataException has popped up multiple number of
> times.
> GEODE-6975
> GEODE-7898
>
> {noformat}
> PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$477/1255368072.run
> in VM 0 running on Host
> heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d.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:448)
> at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testRecoverAfterConflict(PersistentRecoveryOrderDUnitTest.java:1328)
> Caused by:
> org.apache.geode.cache.CacheClosedException: Region
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion remote
> member heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d(585689):51002
> with persistent data
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-1
> created at timestamp 1635009815552 version 0 diskStoreId
> bf4774f44f2e4dcd-aa6c79424132a2e4 name was not part of the same distributed
> system as the local data from
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-0
> created at timestamp 1635009814986 version 0 diskStoreId
> cc4c64d81e9d4119-9e7320b29f540199 name , caused by
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion remote
> member heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d(585689):51002
> with persistent data
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-1
> created at timestamp 1635009815552 version 0 diskStoreId
> bf4774f44f2e4dcd-aa6c79424132a2e4 name was not part of the same distributed
> system as the local data from
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-0
> created at timestamp 1635009814986 version 0 diskStoreId
> cc4c64d81e9d4119-9e7320b29f540199 name
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5223)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getInternalResourceManager(GemFireCacheImpl.java:4259)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getInternalResourceManager(GemFireCacheImpl.java:4253)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1175)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986)
> at
> org.apache.geode.cache.RegionFactory.create(RegionFactory.java:773)
> at
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:75)
> at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.createReplicateRegion(PersistentRecoveryOrderDUnitTest.java:1358)
> at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.createReplicateRegion(PersistentRecoveryOrderDUnitTest.java:1362)
> at
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.lambda$testRecoverAfterConflict$bb17a952$5(PersistentRecoveryOrderDUnitTest.java:1330)
> Caused by:
>
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion
[jira] [Closed] (GEODE-8962) Not possible to escape "$" character in query using LIKE operator
[
https://issues.apache.org/jira/browse/GEODE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-8962.
---
> Not possible to escape "$" character in query using LIKE operator
> -
>
> Key: GEODE-8962
> URL: https://issues.apache.org/jira/browse/GEODE-8962
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {color:#00}If one query tries to match a string containg "$" character by
> a "=" or a "contains" operation, it works, and if data contains a "$"
> character and expression of query looks for it, works as expected.{color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where
> e.key='aa$b'"
> Result : true
> Limit : 100
> Rows : 1
> Result
> --
> aa$b{code}
>
>
> {color:#00}But if we replace the "=" operator in the Geode query by a
> "LIKE" operator, and a wildcard is added, then it seems the regular
> expression mode is somehow triggered and the "$" character starts behaving
> like endline character. That is expected. {color}{color:#172b4d}
> {color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where e.key
> like 'aa$b'"
> Result : true
> Limit : 100
> Rows : 0
> {code}
>
>
> {color:#00}There is no way to escape "$" character.{color}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
[
https://issues.apache.org/jira/browse/GEODE-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10235.
> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> 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.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9277) Constrain Redis FLUSHALL command to local member data only
[
https://issues.apache.org/jira/browse/GEODE-9277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9277.
---
> Constrain Redis FLUSHALL command to local member data only
> --
>
> Key: GEODE-9277
> URL: https://issues.apache.org/jira/browse/GEODE-9277
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Currently our {{FLUSHALL}} command will iterate and delete all keys in the
> whole region. While this is nice and convenient for now, it is not how native
> redis does it and will need to be switched once the function execution layer
> is removed.
> It would be helpful to do this work separately.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9607) radish publish or subscribe operations could run the server out of memory
[ https://issues.apache.org/jira/browse/GEODE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9607. --- > radish publish or subscribe operations could run the server out of memory > - > > Key: GEODE-9607 > URL: https://issues.apache.org/jira/browse/GEODE-9607 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Each subscribe op stores some data in the server memory. If you keep doing > this the server will eventually run out of memory. Operations that store data > are supposed to honor the geode critical memory threshold and fail with a > LowMemory exception but subscribe does no check for critical but instead just > uses more memory. > Each publish op is added to an unbound queue that can take a while to process > (longer when more than one server is running). If enough publish ops are > received in a burst they can also cause the server to run out of memory. > Before adding the op to the queue geode's critical memory threshold should be > checked. > Since the server queues publish ops and needs to send them to remote servers > using a geode function, the implementation should be enhanced to do this with > a batch of publish ops instead of doing them one at a time. This will > improve the performance of publish which will allow it to free up memory > faster. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9436) Implement ZREMRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9436. --- > Implement ZREMRANGEBYSCORE Command > -- > > Key: GEODE-9436 > URL: https://issues.apache.org/jira/browse/GEODE-9436 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [ZREMRANGEBYSCORE|https://redis.io/commands/zremrangebyscore] > command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-8719) CI Failure: org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest > givenServerCrashesDuringAPPEND_thenDataIsNotLost
[
https://issues.apache.org/jira/browse/GEODE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-8719.
---
> CI Failure:
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost
> -
>
> Key: GEODE-8719
> URL: https://issues.apache.org/jira/browse/GEODE-8719
> Project: Geode
> Issue Type: Bug
> Components: redis, tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Sarah Abbey
>Assignee: Jens Deppe
>Priority: Minor
> Labels: flaky-test, unreleased
> Fix For: 1.15.0
>
>
> CI failure: https://concourse.apachegeode-ci.info/builds/207449
> {code:java}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> givenServerCrashesDuringAPPEND_thenDataIsNotLost FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 2
> running on Host e0e2f6af9445 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:460)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:268)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:261)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.startRedisVM(CrashAndNoRepeatDUnitTest.java:131)
> at
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest.givenServerCrashesDuringAPPEND_thenDataIsNotLost(CrashAndNoRepeatDUnitTest.java:164)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> Redis Server using bind address: localhost/127.0.0.1 and port: 44579. Please
> make sure nothing else is running on this address/port combination.
> Caused by:
> java.net.BindException: Address already in use
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
[ https://issues.apache.org/jira/browse/GEODE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9705. --- > When create PR failed with DistributedSystemDisconnectedException, should use > it as cause of PartitionedRegionException > --- > > Key: GEODE-9705 > URL: https://issues.apache.org/jira/browse/GEODE-9705 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When PR failed with register itself, it will throw > DistributedSystemDisconnectedException in cleanupFailedInitialization(). > LockServiceDestroyedException should be the cause of > DistributedSystemDisconnectedException. > Currently, we throw PartitionedRegionException directly using > LockServiceDestroyedException, which is not expected. > The fix is to throw PartitionedRegionException using > DistributedSystemDisconnectedException (or any other RuntimeException) as > cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9495) remove thread sleep from PubSubNativeRedisAcceptanceTest class cleanup
[ https://issues.apache.org/jira/browse/GEODE-9495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9495. --- > remove thread sleep from PubSubNativeRedisAcceptanceTest class cleanup > -- > > Key: GEODE-9495 > URL: https://issues.apache.org/jira/browse/GEODE-9495 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GEODE-9338 includes the addition of a Thread.sleep(24) in the class > cleanup. This wait is necessary to allow the sockets used in this class to > exit the TIME_WAIT state. Out of Mac, Linux, and Windows, Windows has the > longest default TIME_WAIT, which is 240 seconds. So currently at the end of > the PubSubNativeRedisAcceptanceTest tests, we wait for 240 seconds. > Another solution was proposed that involved parsing netstat outputs to find > out when enough sockets have been freed, but the complexity didn't buy us > much there. > A potential other solution would be to reduce the TIME_WAIT period when > running the tests in CI. > If we don't wait for the TIME_WAIT period to be up then other tests being run > after it will get bind exceptions. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9190) Cleanup of Stats Code Warnings
[ https://issues.apache.org/jira/browse/GEODE-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9190. --- > Cleanup of Stats Code Warnings > -- > > Key: GEODE-9190 > URL: https://issues.apache.org/jira/browse/GEODE-9190 > Project: Geode > Issue Type: Improvement > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > There are ton of warnings in the stats files for various reasons. I went > through and cleaned up a bunch of them. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9991.
---
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10319) Stopping the metrics service does not delete its meters
[
https://issues.apache.org/jira/browse/GEODE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10319.
> Stopping the metrics service does not delete its meters
> ---
>
> Key: GEODE-10319
> URL: https://issues.apache.org/jira/browse/GEODE-10319
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Some of Geode's standard meters hold references the cache.
> {{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}}
> closes the meter registry without deleting its meters. As a result, the
> closed registry retains indirect references to the cache, holding the closed
> cache in memory.
> {{clearAndCloseMeterRegistry()}} should clear the registry in addition to
> closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9095) Package splitting geode-http-service
[ https://issues.apache.org/jira/browse/GEODE-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9095. --- > Package splitting geode-http-service > > > Key: GEODE-9095 > URL: https://issues.apache.org/jira/browse/GEODE-9095 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9115) CI failure: org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest > quitWhileSubscribe FAILED
[ https://issues.apache.org/jira/browse/GEODE-9115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9115. --- > CI failure: > org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest > > quitWhileSubscribe FAILED > > > Key: GEODE-9115 > URL: https://issues.apache.org/jira/browse/GEODE-9115 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > See > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/119 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10046. > bump dependencies in 1.16 > - > > Key: GEODE-10046 > URL: https://issues.apache.org/jira/browse/GEODE-10046 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > until support/1.16 is cut, periodically check for and switch to latest > version of 3rd-party dependencies. this will extend the shelf-life of > eventual Geode 1.16 release and hopefully reduce bugs and cve exposure, or at > least give a smaller delta if there is later a cve found that we need to > patch for -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9573) DirectReplySender can fail with UnsupportedOperationException upon connection related exceptions
[
https://issues.apache.org/jira/browse/GEODE-9573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9573.
---
> DirectReplySender can fail with UnsupportedOperationException upon connection
> related exceptions
>
>
> Key: GEODE-9573
> URL: https://issues.apache.org/jira/browse/GEODE-9573
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> java.lang.UnsupportedOperationException
> at java.base/java.util.Collections$1.remove(Collections.java:4714)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:330)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:69)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:115)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:458)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:432)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.scheduleIncomingMessage(ClusterDistributionManager.java:2077)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleIncomingDMsg(ClusterDistributionManager.java:1841)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.dispatchMessage(GMSMembership.java:847)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.handleOrDeferMessage(GMSMembership.java:804)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.processMessage(GMSMembership.java:1102)
> at
> org.apache.geode.distributed.internal.DistributionImpl$MyDCReceiver.messageReceived(DistributionImpl.java:838)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:624)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:682)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3264)
> at
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3015)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2806)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10185) ObjectTraverser cannot traverse a Proxy on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10185.
> ObjectTraverser cannot traverse a Proxy on JDK 17
> -
>
> Key: GEODE-10185
> URL: https://issues.apache.org/jira/browse/GEODE-10185
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> On JDK 17, {{ObjectTraverser}} cannot make fields of a Proxy object's class
> accessible because the class is in an unopened package. JDK 17 creates proxy
> classes in "dynamic" packages created by the JDK as needed. These packages
> cannot be opened when starting the JVM (via {{{}--add-opens{}}}) because the
> packages do not exist at that time.
> {{MemoryOverheadIntegrationTest}} shows this failure in CI integration test
> tasks on JDK 17.
> * Example failure in CI:
> [https://concourse.apachegeode-ci.info/builds/40607693]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7505/test-results/integrationTest/1648496987/]
> Stack trace:
> {noformat}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.reflect.Method jdk.proxy3.$Proxy36.m0 accessible:
> module jdk.proxy3 does not "opens jdk.proxy3" to unnamed module @64c5923
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.geode.internal.size.ObjectTraverser.buildFieldSet(ObjectTraverser.java:116)
> at
> org.apache.geode.internal.size.ObjectTraverser.cacheFieldSet(ObjectTraverser.java:92)
> at
> org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:65)
> at
> org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
> at
> org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> 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
[jira] [Closed] (GEODE-9378) Implement ZRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9378. --- > Implement ZRANGEBYSCORE Command > --- > > Key: GEODE-9378 > URL: https://issues.apache.org/jira/browse/GEODE-9378 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZRANGEBYSCORE|https://redis.io/commands/zrangebyscore] command. > +Acceptance Criteria+ > The ZRANGEBYSCORE command has been implemented along with appropriate unit > tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. > The command has been tested using the redis-cli tool. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9854) Orphaned .drf files causing memory leak
[
https://issues.apache.org/jira/browse/GEODE-9854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9854.
---
> Orphaned .drf files causing memory leak
> ---
>
> Key: GEODE-9854
> URL: https://issues.apache.org/jira/browse/GEODE-9854
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
> Attachments: screenshot-1.png, screenshot-2.png, server1.log
>
>
> Issue:
> An OpLog files are compacted, but the .drf file is left because it contains
> deletes ofentries in previous .crfs. The .crf file is deleted, but the
> orphaned .drf is not until all
> previous .crf files (.crfs with smaller id) are deleted.
> The problem is that compacted Oplog object representing orphaned .drf file
> holds a structure in memory (Oplog.regionMap) that contains information that
> is not useful
> after the compaction and it takes certain amount of memory. Besides, there is
> a race condition in the code when creating .krf files that, depending on the
> execution order,
> could make the problem more severe (it could leave pendingKrfTags structure
> on the regionMap and this could take up a significant amount of memory). This
> pendingKrfTags HashMap is actually empty, but consumes memory because it was
> used previously and the size of the HashMap was not reduced after it is
> cleared.
> This race condition usually happens when new Oplog is rolled out and previous
> Oplog is immediately marked as eligible for compaction. Compaction and .krf
> creation start at
> the similar time and compactor cancels creation of .krf if it is executed
> first. The pendingKrfTags structure is usually cleared when .krf file is
> created, but sincecompaction canceled creation of .krf, the pendingKrfTags
> structure remain in memory until Oplog representing orphaned .drf file is
> deleted.
> Below it can be see that actually .krf is never created for the orphaned .drf
> Oplog object that has memory allocated in pendingKrfTags:
> {code:java}
> server1.log:1956:[info 2021/11/25 21:52:26.866 CET server1
> tid=0x34] Created oplog#129
> drf for disk store store1.
> server1.log:1958:[info 2021/11/25 21:52:26.867 CET server1
> tid=0x34] Created oplog#129
> crf for disk store store1.
> server1.log:1974:[info 2021/11/25 21:52:39.490 CET server1 store1 for oplog oplog#129> tid=0x5c] OplogCompactor for store1 compaction
> oplog id(s): oplog#129
> server1.log:1980:[info 2021/11/25 21:52:39.532 CET server1 store1 for oplog oplog#129> tid=0x5c] compaction did 3685 creates and updates
> in 41 ms
> server1.log:1982:[info 2021/11/25 21:52:39.532 CET server1 Task4> tid=0x5d] Deleted oplog#129 crf for disk store store1.
> {code}
> !screenshot-1.png|width=1123,height=268!
> Below you can see the log and heap dump of orphaned .drf Oplg that dont have
> pendingKrfTags allocated in memory. This is because pendingKrfTags is cleared
> when .krf is created as can be seen in below logs.
> {code:java}
> server1.log:1976:[info 2021/11/25 21:52:39.491 CET server1
> tid=0x34] Created oplog#130
> drf for disk store store1.
> server1.log:1978:[info 2021/11/25 21:52:39.493 CET server1
> tid=0x34] Created oplog#130
> crf for disk store store1.
> server1.log:1998:[info 2021/11/25 21:52:41.131 CET server1 OplogCompactor> tid=0x5c] Created oplog#130 krf for disk store store1.
> server1.log:2000:[info 2021/11/25 21:52:41.893 CET server1 store1 for oplog oplog#130> tid=0x5c|#130> tid=0x5c] OplogCompactor for
> store1 compaction oplog id(s): oplog#130
> server1.log:2002:[info 2021/11/25 21:52:41.958 CET server1 store1 for oplog oplog#130> tid=0x5c|#130> tid=0x5c] compaction did 9918
> creates and updates in 64 ms
> server1.log:2004:[info 2021/11/25 21:52:41.958 CET server1 Task4> tid=0x5d] Deleted oplog#130 crf for disk store store1.
> server1.log:2006:[info 2021/11/25 21:52:41.958 CET server1 Task4> tid=0x5d] Deleted oplog#130 krf for disk store store1.
> {code}
> !screenshot-2.png|width=1123,height=268!
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9256) Remove hscan related fields from redis hash
[
https://issues.apache.org/jira/browse/GEODE-9256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9256.
---
> Remove hscan related fields from redis hash
> ---
>
> Key: GEODE-9256
> URL: https://issues.apache.org/jira/browse/GEODE-9256
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> To implement hscan it looks like we added a number of fields to every redis
> hash.
> {code}
> private ConcurrentHashMap> hScanSnapShots;
> private ConcurrentHashMap hScanSnapShotCreationTimes;
> private ScheduledExecutorService HSCANSnapshotExpirationExecutor = null;
> {code}
> This greatly increases the per hash overhead of radish. We also create
> HSCANSnapshotExpirationExecutor for every hash that has an active hscan,
> potentially using a lot of threads.
> These fields should be removed from the hash itself so we are not increasing
> its overhead. If we need to maintain state related to hscan it should
> probably be in some client specific data structure like the
> ExecutionHandlerContext.
> Redis itself looks like it doesn't maintain any server side state. We should
> use the same stateless cursor algorithm as redis and avoid keeping any state
> on the server. Here's an article that goes in depth on the redis algorithm
> https://www.freecodecamp.org/news/redis-hash-table-scan-explained-537cc8bb9f52/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10284) Add partition-listener option to gfsh create region command
[
https://issues.apache.org/jira/browse/GEODE-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10284.
> Add partition-listener option to gfsh create region command
> ---
>
> Key: GEODE-10284
> URL: https://issues.apache.org/jira/browse/GEODE-10284
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> This adds a {{--partition-listener}} option to the {{create region}} gfsh
> command. I'm not sure why this was not added in the first place since all the
> plumbing to support it already seems to exist.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9685) Improve Test Coverage For SizeableObjectOpenCustomHashSet
[ https://issues.apache.org/jira/browse/GEODE-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9685. --- > Improve Test Coverage For SizeableObjectOpenCustomHashSet > - > > Key: GEODE-9685 > URL: https://issues.apache.org/jira/browse/GEODE-9685 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The > org.apache.geode.redis.internal.collections.SizeableObjectOpenCustomHashSet > class requires test coverage improvement. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9623) Implement the Redis command COMMAND
[ https://issues.apache.org/jira/browse/GEODE-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9623. --- > Implement the Redis command COMMAND > --- > > Key: GEODE-9623 > URL: https://issues.apache.org/jira/browse/GEODE-9623 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the Redis command named [COMMAND|https://redis.io/commands/command]. > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-8616.
---
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1, 1.13.7, 1.14.3, 1.15.0
>Reporter: Donal Evans
>Assignee: Nabarun Nag
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test, pull-request-available,
> testing
> Fix For: 1.15.0
>
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz,
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9333) SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted may fail due to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9333.
---
> SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted
> may fail due to IndexOutOfBoundsException
> -
>
> Key: GEODE-9333
> URL: https://issues.apache.org/jira/browse/GEODE-9333
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> Seen in a PR pre-checkin test run:
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> java.lang.IndexOutOfBoundsException: Index -5 out of bounds for length 100
> at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.util.Objects.checkIndex(Objects.java:372)
> at java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.validateSessionAttributes(SessionsAndCrashesDUnitTest.java:179)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:170)
> {noformat}
> This occurs in the below block when {{totalUpdates}} is less than
> {{NUM_SESSIONS}}.
> {code:java}
> for (int i = totalUpdates - NUM_SESSIONS; i < totalUpdates; i++) {
> int sessionIdx = i % NUM_SESSIONS;
> String sessionId = sessionIds.get(sessionIdx);
> ...
> {code}
> Running the test locally with some trace logging added, it seems that
> {{totalUpdates}} is typically ~120, so if something were to cause updates to
> be 20% slower on a run of the test, this failure could show up. A solution
> might be to either await until at least {{NUM_SESSIONS}} updates have been
> performed by the updater threads, or to put in some logic to handle the case
> when {{totalUpdates}} is less than {{NUM_SESSIONS}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9230) Remove magic numbers in GfshParserAutoCompletionIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9230. --- > Remove magic numbers in GfshParserAutoCompletionIntegrationTest > --- > > Key: GEODE-9230 > URL: https://issues.apache.org/jira/browse/GEODE-9230 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > GfshParserAutoCompletionIntegrationTest uses magic numbers in some tests. > They depend on the number of possible parameters of "start server" command. > That means that when a new parameter is added to the "start server" command, > some tests verifying the gfsh autocompletion feature are impacted, which has > no sense. > The number of parameters can be calculated instead of hardcoded in order to > remove this dependency. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9460) add tests for multi-user mode when one user expires
[ https://issues.apache.org/jira/browse/GEODE-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9460. --- > add tests for multi-user mode when one user expires > --- > > Key: GEODE-9460 > URL: https://issues.apache.org/jira/browse/GEODE-9460 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Current state: > Currently an established client connection does not time out > New state: > Client connections can be subject to time out depending on the security > manager implementation and client code should be able to handle > re-authentication of client connections. > Things to test: > * Test multi-user connections and ensure that when one specific user times > out this user is forced to re-authenticate > * Confirm re-authentication on both new version and versions of the client > in pre 1.13.3 releases > * Confirm the behaviour in single and multi-server environments > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9427) Radish HSCAN implementation does not accept values for CURSOR argument that match Redis
[
https://issues.apache.org/jira/browse/GEODE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9427.
---
> Radish HSCAN implementation does not accept values for CURSOR argument that
> match Redis
> ---
>
> Key: GEODE-9427
> URL: https://issues.apache.org/jira/browse/GEODE-9427
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: unreleased
> Fix For: 1.15.0
>
>
> The HSCAN command takes an argument, CURSOR, which in native Redis can be any
> value between -18446744073709551615 and 18446744073709551615 (the maximum
> value of an unsigned long). The Radish implementation of HSCAN only accepts
> values in the range {{Integer.MIN_VALUE}} -> {{Integer.MAX_VALUE}} and
> returns an error if values outside this range are used.
> The Radish HSCAN implementation should be modified to accept the same range
> of values as Redis. Examples of this can be found in the implementations of
> the currently unsupported SCAN and SSCAN commands.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10080) Upgrade Jedis client in benchmark tests to 4.1.1
[ https://issues.apache.org/jira/browse/GEODE-10080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10080. > Upgrade Jedis client in benchmark tests to 4.1.1 > > > Key: GEODE-10080 > URL: https://issues.apache.org/jira/browse/GEODE-10080 > Project: Geode > Issue Type: Task > Components: benchmarks, redis >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Upgrade Jedis client in benchmark tests to 4.1.1. This is necessary in order > to benchmark support for Redis 6.0 in Geode for Redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9994. --- > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0 > > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9881) Fully recoverd Oplogs object indicating unrecoveredRegionCount>0 preventing compaction
[
https://issues.apache.org/jira/browse/GEODE-9881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9881.
---
> Fully recoverd Oplogs object indicating unrecoveredRegionCount>0 preventing
> compaction
> --
>
> Key: GEODE-9881
> URL: https://issues.apache.org/jira/browse/GEODE-9881
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> We have found problem in case when region is closed with Region.close() and
> then recreated to start the recovery. If you inspect this code in close()
> function you will notice that it doesn't make any sense:
> {code:java}
> void close(DiskRegion dr) {
> // while a krf is being created can not close a region
> lockCompactor();
> try {
> if (!isDrfOnly()) {
> DiskRegionInfo dri = getDRI(dr);
> if (dri != null) {
> long clearCount = dri.clear(null);
> if (clearCount != 0) {
> totalLiveCount.addAndGet(-clearCount);
> // no need to call handleNoLiveValues because we now have an
> // unrecovered region.
> }
> regionMap.get().remove(dr.getId(), dri);
> }
> addUnrecoveredRegion(dr.getId());
> }
> } finally {
> unlockCompactor();
> }
> }
> {code}
> Please notice that addUnrecoveredRegion() marks DiskRegionInfo object as
> unrecovered and increments counter unrecoveredRegionCount. This
> DiskRegionInfo object is contained in regionMap structure. Then afterwards it
> removes DiskRegionInfo object (that was previously marked as unrecovered)
> from the regionMap. This doesn't make any sense, it updated object and then
> removed it from map to be garbage collected. As you will see later on this
> will cause some issues when region is recovered.
> Please check this code at recovery:
> {code:java}
> /**
> * For each dri that this oplog has that is currently unrecoverable check to
> see if a DiskRegion
> * that is recoverable now exists.
> */
> void checkForRecoverableRegion(DiskRegionView dr) {
> if (unrecoveredRegionCount.get() > 0) {
> DiskRegionInfo dri = getDRI(dr);
> if (dri != null) {
> if (dri.testAndSetRecovered(dr)) {
> unrecoveredRegionCount.decrementAndGet();
> }
> }
> }
> }
> {code}
> The problem is that geode will not clear counter unrecoveredRegionCount in
> Oplog objects after recovery is done. This is because
> checkForRecoverableRegion will check unrecoveredRegionCount counter and
> perform testAndSetRecovered. The testAndSetRecovered will always return
> false, because non of the DiskRegionInfo objects in region map have
> unrecovered flag set to true (all object marked as unrecovered were deleted
> by close(), and then they were recreated during recovery see note below).
> The problem here is that all Oplogs will be fully recovered with the counter
> incorrectly indicating unrecoveredRegionCount>0. This will later on prevent
> the compaction of recovered Oplogs (the files that have .crf, .drf and .krf)
> when they reach compaction threshold.
> Note: During recovery regionMap will be recreated from the Oplog files. Since
> all DiskRegionInfo objects are deleted from regionMap during the close(),
> they will be recreated by using function initRecoveredEntry during the
> recovery. All DiskRegionInfo will be created with flag unrecovered set to
> false.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9993. --- > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9390) DistributedSystem nodes is counted twice on each server member
[
https://issues.apache.org/jira/browse/GEODE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9390.
---
> DistributedSystem nodes is counted twice on each server member
> --
>
> Key: GEODE-9390
> URL: https://issues.apache.org/jira/browse/GEODE-9390
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barrett Oglesby
>Assignee: Matthew Reddington
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Once in ClusterDistributionManager.startThreads:
> {noformat}
> [warn 2021/06/20 16:20:16.152 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.153 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=1
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.startThreads(ClusterDistributionManager.java:691)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:504)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
> And once in ClusterDistributionManager.create:
> {noformat}
> [warn 2021/06/20 16:20:16.155 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.156 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=2
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10179. > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
[ https://issues.apache.org/jira/browse/GEODE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9564. --- > Radish ParameterRequirements package name does not follow naming conventions > > > Key: GEODE-9564 > URL: https://issues.apache.org/jira/browse/GEODE-9564 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Per [the style > guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] > adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9525) Add Radish benchmark tests to CI
[ https://issues.apache.org/jira/browse/GEODE-9525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9525. --- > Add Radish benchmark tests to CI > > > Key: GEODE-9525 > URL: https://issues.apache.org/jira/browse/GEODE-9525 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9618) CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
[
https://issues.apache.org/jira/browse/GEODE-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9618.
---
> CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
> ---
>
> Key: GEODE-9618
> URL: https://issues.apache.org/jira/browse/GEODE-9618
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest >
> testConcurrentHdel_whenServerCrashesAndRestarts FAILED
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:78)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.testConcurrentHdel_whenServerCrashesAndRestarts(HdelDUnitTest.java:137)
> Caused by:
> java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:74)
> ... 1 more
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The server
> had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:72)
> at
> io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy50.hdel(Unknown Source)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$null$2(HdelDUnitTest.java:130)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.retryableCommand(HdelDUnitTest.java:146)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$testConcurrentHdel_whenServerCrashesAndRestarts$3(HdelDUnitTest.java:130)
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The
> server had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:110)
> at
> io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120)
> at
> io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.cluster.ClusterCommand.complete(ClusterCommand.java:65)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:746)
> at
> io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:681)
> at
> io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:598)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>
[jira] [Closed] (GEODE-9534) Add tests to verify peer communication when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9534. --- > Add tests to verify peer communication when auth expired > > > Key: GEODE-9534 > URL: https://issues.apache.org/jira/browse/GEODE-9534 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > > When a server joins the cluster, it needs to provide credentials, what if we > expire this credential, will peer to peer communication still succeeds? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
[ https://issues.apache.org/jira/browse/GEODE-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10114. > NullPointerException is logged if create index when cache is closing. > - > > Key: GEODE-10114 > URL: https://issues.apache.org/jira/browse/GEODE-10114 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The following NPE is logged when creating index if cache is closing at the > same time. > [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index idRangeEntryIndex on > region /__PR/_B__QueryRegion0_46 with exception: > java.lang.NullPointerException > [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index > statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with > exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9090) Suspect Strings in Logs DeploymentManagementRedployDUnitTest > redeployJarsWithNewVersionsOfFunctions
[
https://issues.apache.org/jira/browse/GEODE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9090.
---
> Suspect Strings in Logs DeploymentManagementRedployDUnitTest >
> redeployJarsWithNewVersionsOfFunctions
> -
>
> Key: GEODE-9090
> URL: https://issues.apache.org/jira/browse/GEODE-9090
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Suspect strings in logs in this CI run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/107:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctions FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 691
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u)\u\u0004\uDeployCommandRedeployDUnitFunctionA.class\u\u~~n~~@\u0010~~?~~IhChh~~:
> ~~Bp+B~~\u0012E
> EP5P$nJ~~r~~h~~F~~g~~\u\u0017P9~~\u<\u0014b~~qUp~~H\u000fw~~~y\u000f\uO~~ `~~?~~2G\u0006~~%%~~^
> O~~C
>
> i\u0008?~~.w~~Y~~\u000c~~My;~~K\u0006~~\u001c
>
> dl~~\u001a8~~\u0003u1~~OZB#~~mandRedeployDUnitFunctionA.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\u[\u\u\uj\u0002\u\u\u\u
> --uWbis1NkO9dSY3pUDEYgZgkx4bh2w52
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 710
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u:\u\u0004\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\u~~RMo~~@\u0010}~~/\u001b!$\u0016Z'~~j!z+B*~~"~~"~~\u001a(\u0012\u001b9vd~~Q~~7q~~\u000b~~\u001c~~\u0001~~(~~*~~\u0007R~~4~~;\u0007~~=~~\u000c]G\u001b\u001d\u001dw~~X\u00064aC~~\u0026C\u000c~~z~~P~~\u000c~
>
> ~~\u000cd:\u0016~~+>~~Is~~G"N|~~A~~2h~~T8~~"~~#k\u0018Fg~~9\u0011~~'(d~~\u001cb\u000fQ2\u000c~~aOSU=~~\u000c-~~;~~y#\u0015~~gh~~3%~~\u0018~~H~~y*2~vC?x~~\u0016IN~~(L"G\u000cdZ~~u(f~\uS\u001e~~GzL\u0018~~k~~o~~\u0001~~\u0018~~c\u0011~~d|~~a~~.\u001c~~L4q~~ao
>
> wx"\u001c~~y{NR\u0019v~~F?3\u0008\\\u00111~~D~@\\~~\\\u0001Ny\u0017h~~\u001a\u0016:\u000e~~5~~_~~n~~
>
> I~t3~~o`_p~~d-S~~H.`1sh[\u0026~~\u001c~~C~~\u000es~~\u0012C~~|~~J
> \u0017~~w~~44~~/7\u000b
> ~~H~~.\u0017R.\u0016~~Ari\u000e~~V\u0012/_+j)\u0007 X~~
>
> PK\u0007\u0008~~w7\u0001\u\u\u0001\u0004\u\uPK\u0001\u0002\u0014\u\u0014\u\u0008\u0008\u0008\u{4}R~~w7\u0001\u\u\u0001\u0004\u\u:\u\u0004\u\u\u\u\u\u\u\u\u\u\u\u\u\u\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\ul\u\u\uZ\u0002\u\u\u\u
> --XADbzFelszjYv8QsixUwkKt2kmAJrXT6W
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 729
>
>
[jira] [Closed] (GEODE-9962) Redis INFO Command Support for Cluster Mode
[ https://issues.apache.org/jira/browse/GEODE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9962. --- > Redis INFO Command Support for Cluster Mode > --- > > Key: GEODE-9962 > URL: https://issues.apache.org/jira/browse/GEODE-9962 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > The Redis INFO command does not show correct information for cluster mode. > > Research what changes must occur to support the correct information for > cluster mode and ensure tickets are created for tracking. > > +Acceptance Criteria+ > > Gaps in cluster mode supported are identified and tickets are created for > tracking. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9070) CI Failure: ClientServerSessionCacheDUnitTest > addServerToExistingClusterCreatesSessionRegion
[
https://issues.apache.org/jira/browse/GEODE-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9070.
---
> CI Failure: ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion
> --
>
> Key: GEODE-9070
> URL: https://issues.apache.org/jira/browse/GEODE-9070
> Project: Geode
> Issue Type: Bug
> Components: ci, http session
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Sarah Abbey
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest >
> addServerToExistingClusterCreatesSessionRegion FAILED
> 00:47:45org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$84/1299235653.run
> in VM 1 running on Host 51208612ea94 with 4 VMs
> 00:47:45at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 00:47:45at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.addServerToExistingClusterCreatesSessionRegion(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[] within 5 minutes.
> 00:47:45at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 00:47:45at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 00:47:45at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 00:47:45at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$addServerToExistingClusterCreatesSessionRegion$bb17a952$1(ClientServerSessionCacheDUnitTest.java:100)
> 00:47:45
> 00:47:45Caused by:
> 00:47:45java.lang.AssertionError:
> 00:47:45Expected size: 1 but was: 0 in:
> 00:47:45[]
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258)
> 00:47:45at
> org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateServer(ClientServerSessionCacheDUnitTest.java:245)
> 00:47:53{noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-results/distributedTest/161716/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0081/test-artifacts/161716/distributedtestfiles-OpenJDK8-1.15.0-build.0081.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-10111) add COMMITWATCHERS for self-service opt-in/opt-out of automated commit message review
[ https://issues.apache.org/jira/browse/GEODE-10111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10111. > add COMMITWATCHERS for self-service opt-in/opt-out of automated commit > message review > - > > Key: GEODE-10111 > URL: https://issues.apache.org/jira/browse/GEODE-10111 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > previously opt-in and unsubscribe required a dev list email, and this led to > complaints > this self-serve mechanism achieves the same goal of a public record of opt-in > requests, without adding noise to the dev list -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9691) ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed fails sometimes
[
https://issues.apache.org/jira/browse/GEODE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9691.
---
> ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed fails
> sometimes
> -
>
> Key: GEODE-9691
> URL: https://issues.apache.org/jira/browse/GEODE-9691
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Hale Bales
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> fails with the following stack trace:
> {code:java}
> java.util.concurrent.ExecutionException: org.opentest4j.AssertionFailedError:
> expected: 299L
> but was: 0L
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> 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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> 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
>
[jira] [Closed] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
[ https://issues.apache.org/jira/browse/GEODE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9343. --- > Refactoring: move getInfo() method from INFO command to a TestHelper class > -- > > Key: GEODE-9343 > URL: https://issues.apache.org/jira/browse/GEODE-9343 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > the getInfo() method is used throughout our tests to parse the data returned > by the INFO command. There is a lot of duplication of this implementation, > which is risky for future development. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9635. --- > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9864) HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails infrequently
[
https://issues.apache.org/jira/browse/GEODE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9864.
---
> HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails
> infrequently
> --
>
> Key: GEODE-9864
> URL: https://issues.apache.org/jira/browse/GEODE-9864
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jens Deppe
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails
> infrequently with one key's value being null instead of the expected value.
> {code:java}
> java.util.concurrent.ExecutionException: org.opentest4j.AssertionFailedError:
> expected: "set-key-0-1794"
> but was: null
> at
> java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at
> java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908)
> at
> org.apache.geode.redis.internal.executor.hash.HashesAndCrashesDUnitTest.modifyDataWhileCrashingVMs(HashesAndCrashesDUnitTest.java:182)
> at
> org.apache.geode.redis.internal.executor.hash.HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost(HashesAndCrashesDUnitTest.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 java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.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.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
>
[jira] [Closed] (GEODE-9417) ZRANGE Behavior After Deletion of Key Inconsistent With Redis
[ https://issues.apache.org/jira/browse/GEODE-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9417. --- > ZRANGE Behavior After Deletion of Key Inconsistent With Redis > - > > Key: GEODE-9417 > URL: https://issues.apache.org/jira/browse/GEODE-9417 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, redis, unreleased > Fix For: 1.15.0 > > > After deleting a SortedSet the behavior for ZRANGE differs from native Redis. > > +Reproduction Steps:+ > Add some data to a SortedSet: > * ZADD leaderboard 1 "one" > * ZADD leaderboard 2 "two" > Delete the SortedSet with the key "leaderboard": > * DEL leaderboard > Now perform a ZRANGE command on the deleted key > ZRANGE leaderboard 0 10 > > Native Redis returns "(empty array)" where as we return " > "(error) ERR The server had an internal error please try again". > > The same behavior occurs even if the SortedSet never existed. For example: > ZRANGE nonexistent 0 10 will also result in > "(error) ERR The server had an internal error please try again". > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9311) It is possible that JedisCluster client may still retry if the Geode Redis server it is connected to shuts down
[ https://issues.apache.org/jira/browse/GEODE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9311. --- > It is possible that JedisCluster client may still retry if the Geode Redis > server it is connected to shuts down > --- > > Key: GEODE-9311 > URL: https://issues.apache.org/jira/browse/GEODE-9311 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Labels: unreleased > Fix For: 1.15.0 > > > Even after the issue (GEODE-9310) is addressed, the retry issue may still > occur if the JedisCluster client is connected to the node is being shut down. > Here is a test run result: > vm2 gets the command: > [vm2] [warn 2021/05/25 16:01:41.479 PDT server-2 > tid=0x64] Executing Redis command: ZREM key member1-212 member1-211 > member1-214 member1-213 member1-210 member1-209 member1-208 member1-205 > member1-204 > *** command is executed on the primary *** > [vm2] [warn 2021/05/25 16:01:41.503 PDT server-2 Processor2> tid=0x51] bucket region is > BucketRegion[path='/__PR/_B__REDIS__DATA_123;serial=200;primary=true] key key > [vm2] java.lang.Exception > [vm2] at > org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:533) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1213) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:3024) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2236) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > And distributed to replica (vm1): > vm1] [warn 2021/05/25 16:01:41.518 PDT server-1 192.168.0.14(server-2:83136):41002 shared ordered sender uid=7 local > port=58643 remote port=53459> tid=0x59] membersRemoveAll invoked > [vm1] java.lang.Exception > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.membersRemoveAll(RedisSortedSet.java:175) > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.applyDelta(RedisSortedSet.java:89) > [vm1] at > org.apache.geode.redis.internal.data.AbstractRedisData.fromDelta(AbstractRedisData.java:193) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1841) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.setNewValueInRegion(EntryEventImpl.java:1696) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.putExistingEntry(EntryEventImpl.java:1643) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.updateEntry(RegionMapPut.java:485) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.createOrUpdateEntry(RegionMapPut.java:256) > vm2 is bounced: > [vm2] [info 2021/05/25 16:01:41.526 PDT server-2 Connection(1)-192.168.0.14> tid=0x14] Got result: 83136 > [vm2] from org.apache.geode.test.dunit.VM$$Lambda$370/1141741369.call with 0 > args on object: > org.apache.geode.test.dunit.VM$$Lambda$370/1141741369@68ecd55a (took 0 ms) > [info 2021/05/25 16:01:41.527 PDT tid=0x36] Bouncing 2 old > pid is 83136 and version is 10240.0.0 > The JedisCluster client did not get response back (possibly detects > connection is gone), and it does retry again, as the test failed with > following: > java.util.concurrent.ExecutionException: > redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more > cluster attempts left. > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:177) > 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 >
[jira] [Closed] (GEODE-9953) Implement LTRIM
[ https://issues.apache.org/jira/browse/GEODE-9953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9953. --- > Implement LTRIM > --- > > Key: GEODE-9953 > URL: https://issues.apache.org/jira/browse/GEODE-9953 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [LTRIM|https://redis.io/commands/ltrim] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9644) ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects FAILED
[
https://issues.apache.org/jira/browse/GEODE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-9644.
---
> ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects
> FAILED
> --
>
> Key: GEODE-9644
> URL: https://issues.apache.org/jira/browse/GEODE-9644
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> There is sequence of cascading exceptions that occur in the VMs and we need a
> more detailed investigation: Possible culprit may be the bind address in use
> exeception:
> [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0513/test-results/distributedTest/1632566050/*]
>
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest$$Lambda$163/1450009752.run
> in VM 0 running on Host
> heavy-lifter-2c03c48d-8a0c-58ae-bad6-31f64bb5400a.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.waitForLocatorToReconnect(ClusterConfigLocatorRestartDUnitTest.java:225)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects(ClusterConfigLocatorRestartDUnitTest.java:90)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> was not fulfilled within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:908)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.lambda$waitForLocatorToReconnect$f182e747$2(ClusterConfigLocatorRestartDUnitTest.java:226)
> 8300 tests completed, 1 failed, 413 skipped{noformat}
> VM2 mentions that cluster membership has failed.
> {noformat}
> [vm2] [info 2021/09/25 09:36:44.487 UTC server-2
> tid=0x153] cluster membership failed due to
> [vm2]
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> for testing
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1787)
> [vm2] at
> org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper.crashDistributedSystem(MembershipManagerHelper.java:139)
> [vm2] at
> org.apache.geode.test.junit.rules.MemberStarterRule.forceDisconnectMember(MemberStarterRule.java:568)
> [vm2] at
> org.apache.geode.test.dunit.rules.MemberVM.lambda$forceDisconnect$bb17a952$1(MemberVM.java:90)
> [vm2] at
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
> [vm2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm2] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm2] at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> [vm2] at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> [vm2] at
[jira] [Closed] (GEODE-9687) Remove deprecated elements from RegionMembershipMBeanDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9687. --- > Remove deprecated elements from RegionMembershipMBeanDistributedTestBase > > > Key: GEODE-9687 > URL: https://issues.apache.org/jira/browse/GEODE-9687 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9946) Implement LREM Command
[ https://issues.apache.org/jira/browse/GEODE-9946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9946. --- > Implement LREM Command > -- > > Key: GEODE-9946 > URL: https://issues.apache.org/jira/browse/GEODE-9946 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [LREM|https://redis.io/commands/lrem] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-8669) DUnit test failure in PR Pipeline: ClientServerTransactionCCEDUnitTest > testTXDestroy
[
https://issues.apache.org/jira/browse/GEODE-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-8669.
---
> DUnit test failure in PR Pipeline: ClientServerTransactionCCEDUnitTest >
> testTXDestroy
> --
>
> Key: GEODE-8669
> URL: https://issues.apache.org/jira/browse/GEODE-8669
> Project: Geode
> Issue Type: Bug
>Reporter: Sarah Abbey
>Priority: Major
> Fix For: 1.15.0
>
>
> https://concourse.apachegeode-ci.info/builds/202598
> Saw this failure in the PR pipeline:
> {code:java}
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest >
> testTXDestroy FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$25.call in VM 2
> running on Host 94ee13ef1c1a with 4 VMs
> Caused by:
> java.lang.IllegalStateException: Thread does not have an active
> transaction
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
> running on Host 94ee13ef1c1a with 4 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9809. --- > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. > In our test, in cluster with 50 servers, we have leader persisted partitioned > region with more than 1000 buckets, and colocated 2 persisted regions. If we > consecutively create and destroy child regions, memory leak is observed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9389) Implement ZREVRANGEBYLEX Command
[ https://issues.apache.org/jira/browse/GEODE-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9389. --- > Implement ZREVRANGEBYLEX Command > > > Key: GEODE-9389 > URL: https://issues.apache.org/jira/browse/GEODE-9389 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZREVRANGEBYLEX|https://redis.io/commands/zrevrangebylex] > command without the LIMIT option. > > +Acceptance Criteria+ > The ZREVRANGEBYLEX command has been implemented along with appropriate unit > tests. > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10390) User guide: update authentication expiry instructions
[ https://issues.apache.org/jira/browse/GEODE-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10390. > User guide: update authentication expiry instructions > - > > Key: GEODE-10390 > URL: https://issues.apache.org/jira/browse/GEODE-10390 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.15.1 > > > In "Implementing Authentication" indicate that "A SecurityManager > implementation that supports reauthentication using expiring credentials must > also support non-expiring credentials for cluster members” > In "Implementing Authentication Expiry", indicate that "Authentication expiry > is supported only with client connections." -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10122. > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (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 ] Owen Nichols closed GEODE-10126. > 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: Dan Smith >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.7#820007)
[jira] [Closed] (GEODE-9396) Upgrades using SSL fail with mismatch of hostname in certificates
[ https://issues.apache.org/jira/browse/GEODE-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9396. --- > Upgrades using SSL fail with mismatch of hostname in certificates > - > > Key: GEODE-9396 > URL: https://issues.apache.org/jira/browse/GEODE-9396 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.15.0 >Reporter: Ernest Burghardt >Assignee: Bill Burcham >Priority: Major > Labels: pull-request-available, release-blocker > Fix For: 1.15.0 > > > When upgrading from a previous version (prior to 1.14) the ssl handshake will > fail to complete in cases where the Certificate contains a symbolic name that > doesn't match the hostname used by the sslengine. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-8929) Existing log files not counted in disk space calculations
[ https://issues.apache.org/jira/browse/GEODE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-8929. --- > Existing log files not counted in disk space calculations > - > > Key: GEODE-8929 > URL: https://issues.apache.org/jira/browse/GEODE-8929 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When the native logger starts up, it looks for existing "rolled" log files, > i.e. files which were written by a previous instance of the client. If it > finds any, they are added to an internal map, and when the current log file > would exceed the file size limit, the oldest existing rolled log file is > deleted, and a new one written. The size of the existing files, however, is > not calculated and subtracted from available size at startup, so each > concurrent instance of the client can _add_ up to whatever is specified for > `log-disk-space-limit`. So, for instance, if you set a disk space limit of > 5MB, run your app, generate 5MB of logs, and quit, you have 5MB of logs. If > you run your app again, generate 5MB of logs, and quit, you now have 10MB of > logs, etc., effectively "leaking" disk space. > > The workaround for now is to always delete existing log files at app startup, > but we should really either delete these when initializing the logger, or > calculate the existing used disk space at startup. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10343) add ability to opt-in to windows-jdk8 and windows-jdk17 pr checks
[ https://issues.apache.org/jira/browse/GEODE-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10343. > add ability to opt-in to windows-jdk8 and windows-jdk17 pr checks > - > > Key: GEODE-10343 > URL: https://issues.apache.org/jira/browse/GEODE-10343 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Developers can already opt in to jdk8 and jdk17 (on linux) and jdk11 on > windows. This completes the matrix (well, except for Benchmarks) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-8228) CI Failure: SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions
[ https://issues.apache.org/jira/browse/GEODE-8228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-8228. --- > CI Failure: SerialWANStatsDUnitTest > > testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions > --- > > Key: GEODE-8228 > URL: https://issues.apache.org/jira/browse/GEODE-8228 > Project: Geode > Issue Type: Test > Components: ci, wan >Affects Versions: 1.14.0 >Reporter: Ernest Burghardt >Assignee: Jacob Barrett >Priority: Major > Labels: caching-applications, pull-request-available > Fix For: 1.15.0 > > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/247#A] > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-results/distributedTest/1591318846/ > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Test report artifacts from this job are available at: > > > http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0115/test-artifacts/1591318846/distributedtestfiles-OpenJDK8-1.14.0-build.0115.tgz -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9169) Remove Context Switch Between Netty and Command Queue Thread
[ https://issues.apache.org/jira/browse/GEODE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9169. --- > Remove Context Switch Between Netty and Command Queue Thread > > > Key: GEODE-9169 > URL: https://issues.apache.org/jira/browse/GEODE-9169 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.15.0, performance, pull-request-available, > redis > Fix For: 1.15.0 > > > On the current develop branch, the Netty thread reads a message and then puts > it on a queue for another thread to process. Performing the region update > directly on the Netty thread significantly improved performance. > The original behavior was there to support pub/sub use cases, where we need > to push updates to the Netty channel, as well as following Netty best > practices of not blocking the Netty thread. We need to see how we can make > this same change on develop to avoid the context switch while still > supporting pub/sub and not breaking other use cases. > +Acceptance Criteria+ > The context switch between the Netty and command queue thread has been > removed for all commands that are not pub/sub related. > Geode benchmarks perform better after this change for all non-pubsub commands. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9365) HARegionQueue over throttles when multiple threads attempt concurrent adds
[ https://issues.apache.org/jira/browse/GEODE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9365. --- > HARegionQueue over throttles when multiple threads attempt concurrent adds > -- > > Key: GEODE-9365 > URL: https://issues.apache.org/jira/browse/GEODE-9365 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Darrel Schneider >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > HARegionQueue.checkQueueSizeConstraint has some code that implements a > "throttle" on adds to a queue that is full. It is supposed to wait > "eventEnqueueWaitTime" before doing an add. But because this code does two > syncs (putGuard and permitMon) and only waits on one of them, it holds the > other sync for the duration of this threads throttle. Any other concurrent > thread trying to add to the queue gets stuck on the putGuard sync that is > held by the first thread that is doing the timed wait. So it ends up waiting > "eventEnqueueWaitTime" to acquire the first sync and then ends up waiting > again "eventEnqueueWaitTime" when it does its own timed wait. If you have 10 > concurrent threads trying to add one of them will end up waiting 10 * > "eventEnqueueWaitTime". > A couple ideas of how to fix this. Get rid of the putGuard and just use > permitMon. Then as soon as the first thread goes into its timed wait another > thread is allowed to sync on permitMon. But if this is done then we need to > think carefully about the code inside this sync block since it can not be > executed while one or more other threads are waiting in permitMon. > The other solution would be to compute the elapsed time it took to get into > the first sync and subtract that from the time we wait on permitMon. This > seems like a simple solution but does introduce at least one call of get time > (the second call is only needed if the queue is full). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9519) Implement ZSCAN Command
[ https://issues.apache.org/jira/browse/GEODE-9519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9519. --- > Implement ZSCAN Command > --- > > Key: GEODE-9519 > URL: https://issues.apache.org/jira/browse/GEODE-9519 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [ZSCAN|https://redis.io/commands/zscan] command with associated > options, and tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-10034. > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9815. --- > Recovering persistent members can result in extra copies of a bucket or two > copies in the same redundancy zone > -- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, > pull-request-available, unreleased > Fix For: 1.15.0 > > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 > and B1 > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9784) GFSH connect and start server commands should have username option
[ https://issues.apache.org/jira/browse/GEODE-9784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9784. --- > GFSH connect and start server commands should have username option > -- > > Key: GEODE-9784 > URL: https://issues.apache.org/jira/browse/GEODE-9784 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ivan Godwin >Assignee: Ivan Godwin >Priority: Minor > Labels: pull-request-available > Fix For: 1.15.0 > > > When connecting to a secured cluster, --user is available to specify the name > of the user for purpose of authentication and authorization. > - Add --username as option to the connect command that aliases --user, > providing a more intuitively named option > - Add --username as option to the start server command that aliases --user -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9312) Uplift Bookbinder to 10.1.17
[ https://issues.apache.org/jira/browse/GEODE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9312. --- > Uplift Bookbinder to 10.1.17 > > > Key: GEODE-9312 > URL: https://issues.apache.org/jira/browse/GEODE-9312 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Uplift Bookbinder to use new 10.1.17 version, which solves the problems with > mimemagic library reported in GEODE-9042. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-9978) Remove test-container from Geode
[ https://issues.apache.org/jira/browse/GEODE-9978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols closed GEODE-9978. --- > Remove test-container from Geode > > > Key: GEODE-9978 > URL: https://issues.apache.org/jira/browse/GEODE-9978 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > We don't use it for testing anymore. Excise it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols closed GEODE-10119.
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
>
