[jira] [Created] (HBASE-27872) xerial's snappy-java requires GLIBC >= 2.32
Andrew Kyle Purtell created HBASE-27872:
---
Summary: xerial's snappy-java requires GLIBC >= 2.32
Key: HBASE-27872
URL: https://issues.apache.org/jira/browse/HBASE-27872
Project: HBase
Issue Type: Bug
Affects Versions: 2.5.4
Reporter: Andrew Kyle Purtell
Assignee: Andrew Kyle Purtell
Fix For: 2.5.5
We need to add a native library load check with a helpful error message if it
fails to load due to a too old glibc or similar reason, and disable the unit
test if the native library fails to load.
{noformat}
TestHFileCompressionSnappy.test:54->HFileTestBase.doTest:72 »
UnsatisfiedLink
/home/apurtell/src/hbase/hbase-compression/hbase-compression-snappy/target/snappy-1.1.9-6406bd03-44b4-4586-a91b-79d213c14062-libsnappyjava.so:
/lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32'
{noformat}
In this case a Debian test VM has "Debian GLIBC 2.31-13+deb11u6" installed,
which is too load.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-27871) Meta replication stuck forever if wal it's still reading gets rolled and deleted
Wellington Chevreuil created HBASE-27871: Summary: Meta replication stuck forever if wal it's still reading gets rolled and deleted Key: HBASE-27871 URL: https://issues.apache.org/jira/browse/HBASE-27871 Project: HBase Issue Type: Bug Components: meta replicas Affects Versions: 2.5.4, 2.4.17 Reporter: Wellington Chevreuil Assignee: Wellington Chevreuil This affects branch-2 based releases only (in master, HBASE-26416 refactored region replication to not rely on the replication framework anymore). Per the original [meta region replicas design|https://docs.google.com/document/d/1jJWVc-idHhhgL4KDRpjMsQJKCl_NRaCLGiH3Wqwd3O8/edit], we use most of the replication framework for communicating changes in the primary replica back to the secondary ones, but we skip storing the queue state in ZK. In the event of a region replication crash, we should let the related replication source thread be interrupted, so that RegionReplicaReplicationEndpoint would set a new source from the scratch and make sure to update the secondary replicas. We have run into a situation in one of our customers' cluster where the region replica source faced a long lag (probably because the RSes hosting the secondary replicas were busy and slower in processing the region replication entries), so that the current wal got rolled and eventually deleted whilst the replication source reader was still referring it. In such cases, ReplicationSourceReader only sees the IOException and keeps retrying the read indefinitely, but since the file is now gone, it will just get stuck there forever. In the particular case of FNFE (which I believe would only happen for region replication), we should just raise an exception and let RegionReplicaReplicationEndpoint handle it to reset the region replication source. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27870) Eliminate the 'WARNING: package jdk.internal.util.random not in java.base' when running UTs with jdk11
Duo Zhang created HBASE-27870: - Summary: Eliminate the 'WARNING: package jdk.internal.util.random not in java.base' when running UTs with jdk11 Key: HBASE-27870 URL: https://issues.apache.org/jira/browse/HBASE-27870 Project: HBase Issue Type: Improvement Components: build, pom, test Reporter: Duo Zhang Assignee: Duo Zhang When fixing a jdk17 issue, we add a --add-opens java.base/jdk.internal.util.random=ALL-UNNAMED line in our pom when running UTs with jdk11+, so it will also be applied for jdk11, but we only need this for jdk17, on jdk11, it will generate a warning, as described in the title. We should try some maven magics to fix this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
