[ 
https://issues.apache.org/jira/browse/HBASE-28287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-28287.
-------------------------------
    Fix Version/s: 2.6.0
                   2.4.18
                   2.5.8
                   3.0.0-beta-2
     Hadoop Flags: Reviewed
       Resolution: Fixed

Pushed to all active branches.

Thanks [~liuwenjing17] for contributing!

> MOB HFiles are expired earlier than their reference data
> --------------------------------------------------------
>
>                 Key: HBASE-28287
>                 URL: https://issues.apache.org/jira/browse/HBASE-28287
>             Project: HBase
>          Issue Type: Bug
>          Components: mob
>    Affects Versions: 2.5.0
>            Reporter: WenjingLiu
>            Assignee: WenjingLiu
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 2.6.0, 2.4.18, 2.5.8, 3.0.0-beta-2
>
>
> I have observed that mob HFiles are expired earlier than their reference 
> data. Upon reviewing the relevant code, it was observed that the standard 
> expired timestamp is not accurately set. The issue arises from the fact that 
> if we do not set the calendar to the MILLISECOND level, a three-digit random 
> number is appended to the end of the expired timestamp, leading to 
> inaccuracies.
> For instance, if we write mob data to a Time-To-Live (1 day) table at 22:00 
> on 12/20/2023, and the ExpiredMobFileCleaner begins to work at 20:00 on 
> 12/21/2023, the timestamp of the mob HFile will be parsed as 1703001600000, 
> and the StandardExpiredTS is calculated as 1703001600314 with the three-digit 
> random number as MILLISECOND. Consequently, the StandardExpiredTS >= 
> MobHfileTS, thus indicating that the mob HFile should be expired. However, it 
> is observed that this mob HFile only exists for 22 hours, which is less than 
> the specified one-day-time threshold.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to