[jira] [Assigned] (GEODE-10409) Rebalance Model Missing Collocated Regions At Server Startup
[ https://issues.apache.org/jira/browse/GEODE-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Weijie Xu reassigned GEODE-10409: - Assignee: Weijie Xu > Rebalance Model Missing Collocated Regions At Server Startup > > > Key: GEODE-10409 > URL: https://issues.apache.org/jira/browse/GEODE-10409 > Project: Geode > Issue Type: Bug >Reporter: Weijie Xu >Assignee: Weijie Xu >Priority: Major > Labels: needsTriage, pull-request-available > Attachments: server2.log, test.tar.gz > > > Following steps reproduce the issue: > Run the start.gfsh in the attached example, which configures a geode system > with a partitioned region, a gateway sender and a collocated region with the > partitioned region. So there are three regions totally, the leader region, > the collcated region and the queue region. > Then run the example code, which will source ~400M data and 5 times amount of > events into the system. > Then stop one of the server, and revoke the disk file of the server. > Then start the server, which will trigger a bucket recovery. > From the attached log line596, line598 and line5958, we can see that the > queue region is not included in the rebalance model, either in the data size > colum nor in the max size colum. > Then do a manual rebalance after the server is up, this time log shows the > queue region is added to the model.(line6010, line6012, lin6014 and line6028) > > The inconsistent behavior will lead to 2 negative results: > 1) Different result of rebalance between server startup phase and manual > trigger, startup rebalance tells everything is OK, rebalance finished, but > manual trigger rebalance tells space not enough since it included the queue > region into the model which has 5 times data size as the leader region. > 2) A dismatch between the rebalance model and the actual data being > rebalanced(Actually the queue region data is rebalanced although the region > is not included in the model at server startup phase). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10406) Update shiro-core to version 1.9.1 for CVE-2022-32532
[ https://issues.apache.org/jira/browse/GEODE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597986#comment-17597986 ] Alastair commented on GEODE-10406: -- This also impacts Geode 1.15.0, which ships with Shiro 1.9.0. > Update shiro-core to version 1.9.1 for CVE-2022-32532 > -- > > Key: GEODE-10406 > URL: https://issues.apache.org/jira/browse/GEODE-10406 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.7 >Reporter: Ankush Mittal >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2022-32532] > "Apache Shiro before 1.9.1, A RegexRequestMatcher can be misconfigured to be > bypassed on some servlet containers. Applications using RegExPatternMatcher > with `.` in the regular expression are possibly vulnerable to an > authorization bypass." > Geode bundles version 1.8.0 of shiro-core jar which is vulnerable as per the > CVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10413) Upgrade to Jetty 9.4.48.v20220622
Alastair created GEODE-10413: Summary: Upgrade to Jetty 9.4.48.v20220622 Key: GEODE-10413 URL: https://issues.apache.org/jira/browse/GEODE-10413 Project: Geode Issue Type: Bug Affects Versions: 1.15.0 Reporter: Alastair The current version of Geode 1.15.0 uses Jetty 9.4.46.v20220331 which has the following security vulnerabilities: HIGH * CVE-2022-2048 (BDSA-2022-1887) LOW * BDSA-2022-1891 Jetty 9.4.48.v20220622 has no known vulnerabilities. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10413) Upgrade to Jetty 9.4.48.v20220622
[ https://issues.apache.org/jira/browse/GEODE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10413: -- Labels: needsTriage (was: ) > Upgrade to Jetty 9.4.48.v20220622 > - > > Key: GEODE-10413 > URL: https://issues.apache.org/jira/browse/GEODE-10413 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Alastair >Priority: Major > Labels: needsTriage > > The current version of Geode 1.15.0 uses Jetty 9.4.46.v20220331 which has the > following security vulnerabilities: > HIGH > * CVE-2022-2048 (BDSA-2022-1887) > LOW > * BDSA-2022-1891 > Jetty 9.4.48.v20220622 has no known vulnerabilities. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10412) Destry 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
]
Jakov Varenina resolved GEODE-10412.
Fix Version/s: 1.16.0
Resolution: Fixed
> Destry 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
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 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)
