hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-16025) Cache table state to reduce load on META
Date Tue, 14 Jun 2016 22:45:30 GMT

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

Gary Helmling updated HBASE-16025:
----------------------------------
    Description: HBASE-12035 moved keeping table enabled/disabled state from ZooKeeper into
hbase:meta.  When we retry operations on the client, we check table state in order to return
a specific message if the table is disabled.  This means that in master we will be going back
to meta for every retry, even if a region's location has not changed.  This is going to cause
performance issues when a cluster is already loaded, ie. in cases where regionservers may
be returning CallQueueTooBigException.  (was: HBASE-12035 moved keeping table enabled/disabled
state from ZooKeeper into hbase:meta.  When we retry operations on the client, we check table
state in order to return a specific message if the table is disabled.  This means that in
master we will be going back to meta for every retry, even if a region's location has not
changed.)

> Cache table state to reduce load on META
> ----------------------------------------
>
>                 Key: HBASE-16025
>                 URL: https://issues.apache.org/jira/browse/HBASE-16025
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client
>            Reporter: Gary Helmling
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> HBASE-12035 moved keeping table enabled/disabled state from ZooKeeper into hbase:meta.
 When we retry operations on the client, we check table state in order to return a specific
message if the table is disabled.  This means that in master we will be going back to meta
for every retry, even if a region's location has not changed.  This is going to cause performance
issues when a cluster is already loaded, ie. in cases where regionservers may be returning
CallQueueTooBigException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message