[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-04-01 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.5.15, 2.6.6
>
>
> This change removes the unused {{{}incrSplitSuccess(){}}}, 
> {{{}updateSplitTime(){}}}, and related split success/time metrics from 
> RegionServer and Table level metrics sources.
> These metrics {{splitSuccess}} and {{splitTime}} is introduced by 
> HBASE-12779, the split operation has been migrated from RegionServer-driven 
> local execution to Master-driven Procedure-based coordination. When a 
> RegionServer triggers a split due to region size threshold, it only sends a 
> {{READY_TO_SPLIT}} state transition request to the Master via 
> {{{}reportRegionStateTransition(){}}}. The Master then creates a 
> {{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
> process. The RegionServer has no knowledge of when (or whether) the split 
> completes successfully, so it cannot update split success or timing metrics, 
> in HBASE-16549 we refactor split metric logic and start to use 
> {{splitProcMetrics}} tracking the split behaivor
> h3. Current Behavior
>  * Split request metrics ({{{}splitRequestCount{}}}) are properly updated 
> when a split is initiated (RS level)
>  * Split success/time metrics at RegionServer and Table level were defined 
> but never called
>  * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}}, 
> {{{}splitFailedCount{}}}) are correctly maintained via the Procedure 
> framework's {{getProcedureMetrics()}} mechanism
> h3. Changes Made
>  * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from 
> {{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}}, 
> corresponding methods from {{MetricsTableSource}} and 
> {{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram 
> variables
>  * We keep {{SplitRequest}} and support table-level updates for this metic to 
> track split caused by region size exceeds the configured max size
>  
> Call chain 
> {code:java}
> CompactSplit.requestSplit()
> → new SplitRequest(r, midKey, server, user)
> → splits.execute(splitRequest)
> → SplitRequest.run()
> → doSplitting()
> → server.getMetrics().incrSplitRequest(tableName)
> {code}
>  



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


[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-13 Thread Andrew Kyle Purtell (Jira)


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

Andrew Kyle Purtell updated HBASE-29970:

Fix Version/s: 2.5.15
   2.6.6
   (was: 2.6.5)
   (was: 2.5.14)

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.5.15, 2.6.6
>
>
> This change removes the unused {{{}incrSplitSuccess(){}}}, 
> {{{}updateSplitTime(){}}}, and related split success/time metrics from 
> RegionServer and Table level metrics sources.
> These metrics {{splitSuccess}} and {{splitTime}} is introduced by 
> HBASE-12779, the split operation has been migrated from RegionServer-driven 
> local execution to Master-driven Procedure-based coordination. When a 
> RegionServer triggers a split due to region size threshold, it only sends a 
> {{READY_TO_SPLIT}} state transition request to the Master via 
> {{{}reportRegionStateTransition(){}}}. The Master then creates a 
> {{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
> process. The RegionServer has no knowledge of when (or whether) the split 
> completes successfully, so it cannot update split success or timing metrics, 
> in HBASE-16549 we refactor split metric logic and start to use 
> {{splitProcMetrics}} tracking the split behaivor
> h3. Current Behavior
>  * Split request metrics ({{{}splitRequestCount{}}}) are properly updated 
> when a split is initiated (RS level)
>  * Split success/time metrics at RegionServer and Table level were defined 
> but never called
>  * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}}, 
> {{{}splitFailedCount{}}}) are correctly maintained via the Procedure 
> framework's {{getProcedureMetrics()}} mechanism
> h3. Changes Made
>  * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from 
> {{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}}, 
> corresponding methods from {{MetricsTableSource}} and 
> {{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram 
> variables
>  * We keep {{SplitRequest}} and support table-level updates for this metic to 
> track split caused by region size exceeds the configured max size
>  
> Call chain 
> {code:java}
> CompactSplit.requestSplit()
> → new SplitRequest(r, midKey, server, user)
> → splits.execute(splitRequest)
> → SplitRequest.run()
> → doSplitting()
> → server.getMetrics().incrSplitRequest(tableName)
> {code}
>  



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


[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Description: 
This change removes the unused {{{}incrSplitSuccess(){}}}, 
{{{}updateSplitTime(){}}}, and related split success/time metrics from 
RegionServer and Table level metrics sources.

These metrics {{splitSuccess}} and {{splitTime}} is introduced by HBASE-12779, 
the split operation has been migrated from RegionServer-driven local execution 
to Master-driven Procedure-based coordination. When a RegionServer triggers a 
split due to region size threshold, it only sends a {{READY_TO_SPLIT}} state 
transition request to the Master via {{{}reportRegionStateTransition(){}}}. The 
Master then creates a {{SplitTableRegionProcedure}} to asynchronously 
coordinate the entire split process. The RegionServer has no knowledge of when 
(or whether) the split completes successfully, so it cannot update split 
success or timing metrics, in HBASE-16549 we refactor split metric logic and 
start to use {{splitProcMetrics}} tracking the split behaivor
h3. Current Behavior
 * Split request metrics ({{{}splitRequestCount{}}}) are properly updated when 
a split is initiated (RS level)
 * Split success/time metrics at RegionServer and Table level were defined but 
never called
 * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}}, 
{{{}splitFailedCount{}}}) are correctly maintained via the Procedure 
framework's {{getProcedureMetrics()}} mechanism

h3. Changes Made
 * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from 
{{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}}, 
corresponding methods from {{MetricsTableSource}} and 
{{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram 
variables
 * We keep {{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size

 

Call chain 
{code:java}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}
 

  was:
This change removes the unused {{{}incrSplitSuccess(){}}}, 
{{{}updateSplitTime(){}}}, and related split success/time metrics from 
RegionServer and Table level metrics sources.

These metrics {{splitSuccess}} and {{splitTime}} is introduced by HBASE-12779, 
the split operation has been migrated from RegionServer-driven local execution 
to Master-driven Procedure-based coordination. When a RegionServer triggers a 
split due to region size threshold, it only sends a {{READY_TO_SPLIT}} state 
transition request to the Master via {{{}reportRegionStateTransition(){}}}. The 
Master then creates a {{SplitTableRegionProcedure}} to asynchronously 
coordinate the entire split process. The RegionServer has no knowledge of when 
(or whether) the split completes successfully, so it cannot update split 
success or timing metrics, in HBASE-16549 we refactor split metric logic and 
start to use {{splitProcMetrics}} tracking the split behaivor
h3. Current Behavior
 * Split request metrics ({{{}splitRequestCount{}}}) are properly updated when 
a split is initiated (RS level)
 * Split success/time metrics at RegionServer and Table level were defined but 
never called
 * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}}, 
{{{}splitFailedCount{}}}) are correctly maintained via the Procedure 
framework's {{getProcedureMetrics()}} mechanism

h3. Changes Made
 * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from 
{{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}}, 
corresponding methods from {{MetricsTableSource}} and 
{{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram 
variables
 * We keep {{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size

{code:java}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}
 


> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> This change removes the unused {{{}incrSplitSuccess(){}}}, 
> {{{}updateSplitTime(){}}}, and related split success/ti

[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Description: 
This change removes the unused {{{}incrSplitSuccess(){}}}, 
{{{}updateSplitTime(){}}}, and related split success/time metrics from 
RegionServer and Table level metrics sources.

These metrics {{splitSuccess}} and {{splitTime}} is introduced by HBASE-12779, 
the split operation has been migrated from RegionServer-driven local execution 
to Master-driven Procedure-based coordination. When a RegionServer triggers a 
split due to region size threshold, it only sends a {{READY_TO_SPLIT}} state 
transition request to the Master via {{{}reportRegionStateTransition(){}}}. The 
Master then creates a {{SplitTableRegionProcedure}} to asynchronously 
coordinate the entire split process. The RegionServer has no knowledge of when 
(or whether) the split completes successfully, so it cannot update split 
success or timing metrics, in HBASE-16549 we refactor split metric logic and 
start to use {{splitProcMetrics}} tracking the split behaivor
h3. Current Behavior
 * Split request metrics ({{{}splitRequestCount{}}}) are properly updated when 
a split is initiated (RS level)
 * Split success/time metrics at RegionServer and Table level were defined but 
never called
 * Master-side split metrics ({{{}splitSubmittedCount{}}}, {{{}splitTime{}}}, 
{{{}splitFailedCount{}}}) are correctly maintained via the Procedure 
framework's {{getProcedureMetrics()}} mechanism

h3. Changes Made
 * Removed {{incrSplitSuccess()}} and {{updateSplitTime()}} methods from 
{{MetricsRegionServerSource}} and {{{}MetricsRegionServerSourceImpl{}}}, 
corresponding methods from {{MetricsTableSource}} and 
{{{}MetricsTableSourceImpl{}}}, and related metric definitions and histogram 
variables
 * We keep {{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size

{code:java}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}
 

  was:
This change removes the unused \{{incrSplitSuccess()}}, \{{updateSplitTime()}}, 
and related split success/time metrics from RegionServer and Table level 
metrics sources.

These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by 
HBASE-12779, the split operation has been migrated from RegionServer-driven 
local execution to Master-driven Procedure-based coordination. When a 
RegionServer triggers a split due to region size threshold, it only sends a 
\{{READY_TO_SPLIT}} state transition request to the Master via 
\{{reportRegionStateTransition()}}. The Master then creates a 
\{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
process. The RegionServer has no knowledge of when (or whether) the split 
completes successfully, so it cannot update split success or timing metrics, in 
HBASE-16549 we refactor split metric logic and start to use 
\{{splitProcMetrics}} tracking the split behaivor

h3. Current Behavior


* Split request metrics (\{{splitRequestCount}}) are properly updated when a 
split is initiated
* Split success/time metrics at RegionServer and Table level were defined but 
never called
* Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}}, 
\{{splitFailedCount}}) are correctly maintained via the Procedure framework's 
\{{getProcedureMetrics()}} mechanism

h3. Changes Made


* Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from 
\{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}}, 
corresponding methods from \{{MetricsTableSource}} and 
\{{MetricsTableSourceImpl}}, and related metric definitions and histogram 
variables
* We keep \{{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size

{code:language=bash|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}

 


> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> This change removes the unused {{{}incrSplitSuccess(){}}}, 
> {{{}updateSplitTime(){}}

[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Description: 
This change removes the unused \{{incrSplitSuccess()}}, \{{updateSplitTime()}}, 
and related split success/time metrics from RegionServer and Table level 
metrics sources.

These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by 
HBASE-12779, the split operation has been migrated from RegionServer-driven 
local execution to Master-driven Procedure-based coordination. When a 
RegionServer triggers a split due to region size threshold, it only sends a 
\{{READY_TO_SPLIT}} state transition request to the Master via 
\{{reportRegionStateTransition()}}. The Master then creates a 
\{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
process. The RegionServer has no knowledge of when (or whether) the split 
completes successfully, so it cannot update split success or timing metrics, in 
HBASE-16549 we refactor split metric logic and start to use 
\{{splitProcMetrics}} tracking the split behaivor

h3. Current Behavior


* Split request metrics (\{{splitRequestCount}}) are properly updated when a 
split is initiated
* Split success/time metrics at RegionServer and Table level were defined but 
never called
* Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}}, 
\{{splitFailedCount}}) are correctly maintained via the Procedure framework's 
\{{getProcedureMetrics()}} mechanism

h3. Changes Made


* Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from 
\{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}}, 
corresponding methods from \{{MetricsTableSource}} and 
\{{MetricsTableSourceImpl}}, and related metric definitions and histogram 
variables
* We keep \{{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size

{code:language=bash|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
CompactSplit.requestSplit()
→ new SplitRequest(r, midKey, server, user)
→ splits.execute(splitRequest)
→ SplitRequest.run()
→ doSplitting()
→ server.getMetrics().incrSplitRequest(tableName)
{code}

 

  was:
This change removes the unused \{{incrSplitSuccess()}}, \{{updateSplitTime()}}, 
and related split success/time metrics from RegionServer and Table level 
metrics sources.

These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by 
HBASE-12779, the split operation has been migrated from RegionServer-driven 
local execution to Master-driven Procedure-based coordination. When a 
RegionServer triggers a split due to region size threshold, it only sends a 
\{{READY_TO_SPLIT}} state transition request to the Master via 
\{{reportRegionStateTransition()}}. The Master then creates a 
\{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
process. The RegionServer has no knowledge of when (or whether) the split 
completes successfully, so it cannot update split success or timing metrics, in 
HBASE-16549 we refactor split metric logic and start to use 
\{{splitProcMetrics}} tracking the split behaivor

h3. Current Behavior


* Split request metrics (\{{splitRequestCount}}) are properly updated when a 
split is initiated
* Split success/time metrics at RegionServer and Table level were defined but 
never called
* Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}}, 
\{{splitFailedCount}}) are correctly maintained via the Procedure framework's 
\{{getProcedureMetrics()}} mechanism

h3. Changes Made


* Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from 
\{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}}, 
corresponding methods from \{{MetricsTableSource}} and 
\{{MetricsTableSourceImpl}}, and related metric definitions and histogram 
variables
* We keep \{{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size
* 
\{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
* CompactSplit.requestSplit()
* → new SplitRequest(r, midKey, server, user)
* → splits.execute(splitRequest)
* → SplitRequest.run()
* → doSplitting()
* → server.getMetrics().incrSplitRequest(tableName)
* \{code}

 


> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> This change removes the un

[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Description: 
This change removes the unused \{{incrSplitSuccess()}}, \{{updateSplitTime()}}, 
and related split success/time metrics from RegionServer and Table level 
metrics sources.

These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by 
HBASE-12779, the split operation has been migrated from RegionServer-driven 
local execution to Master-driven Procedure-based coordination. When a 
RegionServer triggers a split due to region size threshold, it only sends a 
\{{READY_TO_SPLIT}} state transition request to the Master via 
\{{reportRegionStateTransition()}}. The Master then creates a 
\{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
process. The RegionServer has no knowledge of when (or whether) the split 
completes successfully, so it cannot update split success or timing metrics, in 
HBASE-16549 we refactor split metric logic and start to use 
\{{splitProcMetrics}} tracking the split behaivor

h3. Current Behavior


* Split request metrics (\{{splitRequestCount}}) are properly updated when a 
split is initiated
* Split success/time metrics at RegionServer and Table level were defined but 
never called
* Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}}, 
\{{splitFailedCount}}) are correctly maintained via the Procedure framework's 
\{{getProcedureMetrics()}} mechanism

h3. Changes Made


* Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from 
\{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}}, 
corresponding methods from \{{MetricsTableSource}} and 
\{{MetricsTableSourceImpl}}, and related metric definitions and histogram 
variables
* We keep \{{SplitRequest}} and support table-level updates for this metic to 
track split caused by region size exceeds the configured max size
* 
\{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
* CompactSplit.requestSplit()
* → new SplitRequest(r, midKey, server, user)
* → splits.execute(splitRequest)
* → SplitRequest.run()
* → doSplitting()
* → server.getMetrics().incrSplitRequest(tableName)
* \{code}

 

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>
> This change removes the unused \{{incrSplitSuccess()}}, 
> \{{updateSplitTime()}}, and related split success/time metrics from 
> RegionServer and Table level metrics sources.
> These metrics \{{splitSuccess}} and \{{splitTime}} is introduced by 
> HBASE-12779, the split operation has been migrated from RegionServer-driven 
> local execution to Master-driven Procedure-based coordination. When a 
> RegionServer triggers a split due to region size threshold, it only sends a 
> \{{READY_TO_SPLIT}} state transition request to the Master via 
> \{{reportRegionStateTransition()}}. The Master then creates a 
> \{{SplitTableRegionProcedure}} to asynchronously coordinate the entire split 
> process. The RegionServer has no knowledge of when (or whether) the split 
> completes successfully, so it cannot update split success or timing metrics, 
> in HBASE-16549 we refactor split metric logic and start to use 
> \{{splitProcMetrics}} tracking the split behaivor
> h3. Current Behavior
> * Split request metrics (\{{splitRequestCount}}) are properly updated when a 
> split is initiated
> * Split success/time metrics at RegionServer and Table level were defined but 
> never called
> * Master-side split metrics (\{{splitSubmittedCount}}, \{{splitTime}}, 
> \{{splitFailedCount}}) are correctly maintained via the Procedure framework's 
> \{{getProcedureMetrics()}} mechanism
> h3. Changes Made
> * Removed \{{incrSplitSuccess()}} and \{{updateSplitTime()}} methods from 
> \{{MetricsRegionServerSource}} and \{{MetricsRegionServerSourceImpl}}, 
> corresponding methods from \{{MetricsTableSource}} and 
> \{{MetricsTableSourceImpl}}, and related metric definitions and histogram 
> variables
> * We keep \{{SplitRequest}} and support table-level updates for this metic to 
> track split caused by region size exceeds the configured max size
> * 
> \{code:language=|borderStyle=solid|theme=RDark|linenumbers=true|collapse=false}
> * CompactSplit.requestSplit()
> * → new SplitRequest(r, midKey, server, user)
> * → splits.execute(splitRequest)
> * → SplitRequest.run()
> * → doSplitting()
> * → server.getMetri

[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Attachment: (was: image-2026-03-06-20-44-06-885.png)

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>




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


[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-06 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Attachment: image-2026-03-06-20-44-06-885.png

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>




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


[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-05 Thread Xiao Liu (Jira)


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

Xiao Liu updated HBASE-29970:
-
Status: Patch Available  (was: In Progress)

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>




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


[jira] [Updated] (HBASE-29970) SplitSuccess and SplitTime metrics are no longer used at RegionServer and Table level

2026-03-05 Thread ASF GitHub Bot (Jira)


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

ASF GitHub Bot updated HBASE-29970:
---
Labels: pull-request-available  (was: )

> SplitSuccess and SplitTime metrics are no longer used at RegionServer and 
> Table level
> -
>
> Key: HBASE-29970
> URL: https://issues.apache.org/jira/browse/HBASE-29970
> Project: HBase
>  Issue Type: Improvement
>  Components: metrics
>Reporter: Xiao Liu
>Assignee: Xiao Liu
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.6.5, 2.5.14
>
>




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