[jira] [Created] (HBASE-28386) Potential Data loss issue for the HFLog
Dong0829 created HBASE-28386: Summary: Potential Data loss issue for the HFLog Key: HBASE-28386 URL: https://issues.apache.org/jira/browse/HBASE-28386 Project: HBase Issue Type: Bug Components: wal Reporter: Dong0829 Attachments: Screenshot 2024-02-19 at 10.53.20.png I am going through the WAL implementation HFLog, and based on the code reading, as my understanding there maybe potential data loss for example in below scenarios: # Append record A3 already into the stream, and but the syncFuture S3 does not reach to the SyncRunner yet # The SyncRunner run the sync and call sync on writer, but failed, all the data in stream lost including A3 # Because the syncFuture S3 does not reach to the syncRunner, it can not release it and mark it failed # In next run() of the SyncRunner, the new sync() succeeded, it will release and mark S3 as succeeded, but actually it should failed which cause data loss. Can anyone help to check above above is true? Am I missing anything regarding this process? !Screenshot 2024-02-19 at 10.53.20.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28385) Quota estimates are too optimistic for large scans
Ray Mattingly created HBASE-28385: - Summary: Quota estimates are too optimistic for large scans Key: HBASE-28385 URL: https://issues.apache.org/jira/browse/HBASE-28385 Project: HBase Issue Type: Improvement Reporter: Ray Mattingly Fix For: 2.6.0 Let's say you're running a table scan with a throttle of 100MB/sec per RegionServer. Ideally your scans are going to pull down large results, often containing hundreds or thousands of blocks. You will estimate each scan as costing a single block of read capacity, and if your quota is already exhausted then the server will evaluate the backoff required for your estimated consumption (1 block) to be available. This will often be ~1ms, causing your retries to basically be immediate. Obviously it will routinely take much longer than 1ms for 100MB of IO to become available in the given configuration, so your retries will be destined to fail. At worst this can cause a saturation of your server's RPC layer, and at best this causes erroneous exhaustion of the client's retries. We should find a way to make these estimates a bit smarter for large scans. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-28384) Client ingegration tests fails for branch-2/branch-2.6
Duo Zhang created HBASE-28384: - Summary: Client ingegration tests fails for branch-2/branch-2.6 Key: HBASE-28384 URL: https://issues.apache.org/jira/browse/HBASE-28384 Project: HBase Issue Type: Bug Components: hadoop3, jenkins Reporter: Duo Zhang In HBASE-28331, we fixed the problem that we should use the latest hadoop3 tarballs, for generating hdfs-site.xml. But for branch-2.x, we still use hadoop2 when compiling hbase by default, so there is no org.apache.hadoop.ipc.ProtobufRpcEngine2 class. But the hadoop 3.3.x will generate hdfs-site.xml with this config, then leads to the failure of hbase start up. Should we change to build with hadoop3 while running on top of hadoop3? Since for branch-2.x, we will publish artifacts for hadoop3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Community Over Code Asia 2024 Travel Assistance Applications now open!
Hello to all users, contributors and Committers! The Travel Assistance Committee (TAC) are pleased to announce that travel assistance applications for Community over Code Asia 2024 are now open! We will be supporting Community over Code Asia, Hangzhou, China July 26th - 28th, 2024. TAC exists to help those that would like to attend Community over Code events, but are unable to do so for financial reasons. For more info on this year's applications and qualifying criteria, please visit the TAC website at < https://tac.apache.org/ >. Applications are already open on https://tac-apply.apache.org/, so don't delay! The Apache Travel Assistance Committee will only be accepting applications from those people that are able to attend the full event. Important: Applications close on Friday, May 10th, 2024. Applicants have until the the closing date above to submit their applications (which should contain as much supporting material as required to efficiently and accurately process their request), this will enable TAC to announce successful applications shortly afterwards. As usual, TAC expects to deal with a range of applications from a diverse range of backgrounds; therefore, we encourage (as always) anyone thinking about sending in an application to do so ASAP. For those that will need a Visa to enter the Country - we advise you to apply now so that you have enough time in case of interview delays. So do not wait until you know if you have been accepted or not. We look forward to greeting many of you in Hangzhou, China in July, 2024! Kind Regards, Gavin (On behalf of the Travel Assistance Committee)
[jira] [Created] (HBASE-28383) Update hbase-env.sh with alternates to JVM flags which are no longer supported with JDK17
Nihal Jain created HBASE-28383:
--
Summary: Update hbase-env.sh with alternates to JVM flags which
are no longer supported with JDK17
Key: HBASE-28383
URL: https://issues.apache.org/jira/browse/HBASE-28383
Project: HBase
Issue Type: Improvement
Reporter: Nihal Jain
Assignee: Nihal Jain
Some JVM flags like {{{}-XX:+PrintGCDetails{}}}, {{-XX:+PrintGCDateStamps}}
etc. are no longer supported with JDK 17 and hbase would fail to start if these
are passed.
We should do an audit and update
[https://github.com/apache/hbase/blob/master/conf/hbase-env.sh] to capture
alternate/fix.
Will refer following for a fix/repalacement:
*
[https://stackoverflow.com/questions/54144713/is-there-a-replacement-for-the-garbage-collection-jvm-args-in-java-11]
*
[https://docs.oracle.com/javase/9/tools/java.htm#GUID-BE93ABDC-999C-4CB5-A88B-1994AAAC74D5__CONVERTGCLOGGINGFLAGSTOXLOG-A5046BD1]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
