nirdosh0110 commented on PR #8584: URL: https://github.com/apache/hbase/pull/8584#issuecomment-5816143323
> > Both CLOSE-time and OPEN-time seeding would fix this. Reasons I kept OPEN-time: > > > > * `openSeqNum` ≥ close-marker, so it's an at-least-as-tight fence. > > * Fires on every OPEN (reassignment after SCP, master restart, RS restart), not only clean closes. > > * Reuses the existing `reportRegionOpen` payload that already carries `openSeqNum` — no new field on the close report. > > But this will still leave a small gap where Close is completed and OPEN is yet to happen. And SCP of source is already started and we are about to split the wal. This is the reason why I wanted to do it with `reportRegionClose` . Because flush is something related to close only not open. So it would make sense if we do this while closing. Good point @Umeshkumar9414, and I agree it's worth doing. The OPEN-time seed here is the primary fence — openSeqNum ≥ close-marker, and it fires on every reopen path (reassignment after SCP, master restart, RS restart), including the pure-crash case where there's no close report at all. But you're right that it leaves the narrow window you describe: close done on the source, source dies, its SCP splits the WAL before the target finishes OPEN. Seeding on CLOSE tightens exactly that window for the graceful-close case, and it composes cleanly with the OPEN seed since both go through the same monotonic merge(Math::max). The plumbing is already there — the CLOSED transition is routed through the same handler that receives a seqId, the RS can source it from HRegion.getMaxFlushedSeqId(), and RegionStateTransition already has the optional openSeqNum field, so no proto change is needed. I'd prefer to keep this PR's diff focused on the OPEN-time seed (it's approved and the heartbeat race is now fixed) and do the close-time seed as a small follow-up — same way we split out HBASE-30352. Filed it as HBASE-XXXXX; I'll pick it up there. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
