Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 29 Jan 2014 12:56:09 +0000 (UTC)
From: "Jonathan Hsieh (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12691941.1390953175426.2694.1391000169836@arcas>
In-Reply-To: <JIRA.12691941.1390953175426@arcas>
References: <JIRA.12691941.1390953175426@arcas>
Subject: [jira] [Commented] (HBASE-10436) hbase 0.96+ jmx metrics do not
 have regionserver info any more.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13885308#comment-13885308 ] 

Jonathan Hsieh commented on HBASE-10436:
----------------------------------------

bq. First this patch only addresses jmx and not the actual metrics system. (See how the other HMaster metrics are exposed; Interfaces in hbase-hadoop-compat and implementations in hbase-hadoop1|2-compat)

This is intentional and actually the point.  It is pretty clear from the JMX (java management extensions) documentation [1] that it is a *management* interface - not just a *metrics* interface.  It is intended to be a common interface for managing java services.  Services could be designed to accept input and provide information all via the JMX interface and could be designed (if facilities were provided) to manage and runtime configuration changes.

I do agree that I should remove the word "metrics" from the jira name.  

bq. Secondly, This will synchronize on the online servers list everytime that JMX is polled. That seems pretty onerous for exposing the list of region servers. That api already exists; We should have one way of getting that list, not multiple.

Having separate jmx modules allows the user to selectively poll information and thus avoid any cost associated with gathering the online regionserver list [2].  Furthermore, this is at the master and I contend that any synchronization would actually be fairly cheap -- I don't believe there is evidence that there is high contention on this online regionserver list.  This only retrieves info when polled - its is not a "NotificationEmmitter".   If it was truly onerous, I would make the same argument that we shouldn't provide this info in the hbase master webpage and we dare not auto refresh the page (what a NotificationEmitter would do) because of the synchronization costs.  

bq. Thirdly I disagree that the metrics api should be treated like the user api.

JMX is a management api protocol not just meant to server metrics.

Do external programs plug into this api?  Does a user have to change code if the api changes?  yes. 
Should users need to significantly modify their applications when deciding to upgrade?  ideally no.
There is a concept of versioning apis and metrics -- ideally we should have used that approach.  Instead for this transition our users would have to validate "modelerType" and "name" attributes. 

bq. We told users the metrics would change very early in 0.95

Removal is different is generally called out and not just a change.  We preserved functionality when we changed the signature of methods to use ServerName. We didn't change rowlocks, we removed them. 

Regarding the examples -- each hlog or memstore implementation would have a different bean.  The refactoring that split the metrics into separate beans was a really good thing -- I believe that IPC, memstore and hlog is already split out into separate jmx beans.  This split allows for different flavors with different implementations.  I would hope that there would be common attributes regardless of what kind of future hlogs come to be -- (# of kvs or waledits written will always be hlog concepts regardless of its implementation details).  

[1]  http://docs.oracle.com/javase/tutorial/jmx/overview/index.html
[2] http://docs.oracle.com/cd/E13222_01/wls/docs100/jmxinst/understanding.html#wp1100632

> hbase 0.96+ jmx metrics do not have regionserver info any more.
> ---------------------------------------------------------------
>
>                 Key: HBASE-10436
>                 URL: https://issues.apache.org/jira/browse/HBASE-10436
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.0, 0.96.0, 0.99.0
>            Reporter: Jonathan Hsieh
>            Assignee: Jonathan Hsieh
>            Priority: Critical
>         Attachments: hbase-10436.patch
>
>
> HBase 0.96's refactored jmx beans do not contain the master's list of dead region servers and live regionservers with load info.  HBase 0.94 did (though in a single monolithic blob).  
> This JMX interface should be considered as much of an API as the the normal wire or java api.  Dropping values from this was done without deprecation and the removal of this information is a functional regression.
> We should provide the information in the 0.96+ JMX.  HBase 0.94 had a  monolithic JMX blob ("hadoop:service=Master,name=Master")  that contained a lot of information, including the regionserver list and the cached regionserver load for each region  found on the master webpage.  0.96+ refactored jmx this into several jmx beans which could be selectively retrieved.  These include:
> * hadoop:service=HBase,name=Master,sub=AssignmentManager
> * hadoop:service=HBase,name=Master,sub=Balancer
> * hadoop:service=HBase,name=Master,sub=Server
> * hadoop:service=HBase,name=Master,sub=FileSystem
> Specifically the (Hadoop:service=HBase,name=Master,sub=Server) listing that used to contain regionservers and deadregionservers in jmx were replaced in   with numRegionServers and numDeadRegionservers which only contain counts.  
> I propose just adding another mbean called "RegionServers" under the bean: "hadoop:service=HBase,name=Master,sub=RegionServers"


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)