hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HBASE-533) Region Historian
Date Wed, 28 May 2008 23:44:45 GMT

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

Jean-Daniel Cryans updated HBASE-533:
-------------------------------------

    Attachment: hbase-533-v1-fix.patch

Added missing file (regionhistorian.jsp)

The sample is taken from the regionhistorian page. It does have two creations like if two
HRegion were created for a single one (the constructor is called two times so I guess two
different objects with same name). I thought someone would explain this to me instead of searching
why ;)

I buy the level of detail idea, should I make it static or dynamic?

Regards the getRow comment, it is to me related to HBASE-33. Having a getRow method that returns
everything it contains is, IMO, logic.

Sorry for the sysouts, it is my personnal debug info, won't be there in a review version of
this patch.

> Region Historian
> ----------------
>
>                 Key: HBASE-533
>                 URL: https://issues.apache.org/jira/browse/HBASE-533
>             Project: Hadoop HBase
>          Issue Type: Wish
>            Reporter: Bryan Duxbury
>            Assignee: Jean-Daniel Cryans
>            Priority: Minor
>         Attachments: hbase-533-v1-fix.patch, hbase-533-v1.patch
>
>
> Whenever we try to debug region splitting, assignment, compaction, etc. issues, we always
end up having to look in 1-20 different log files for cryptic names of regions and try to
piece together the chain of events ourselves. This is a challenging at best effort most of
the time.
> What would be very useful would be a new utility I've nicknamed the Region Historian.
You give it the text name of a region, and it will track down the log messages relevant to
it in the master and regionserver logs. Then, it will interleave the messages in such a way
that the timestamps correctly list the order of events. The result is a log summary that accurately
describes what happened to a region during it's lifetime, making it much easier to try and
figure out where something went wrong.
> Other things it could do would be replace cryptic log messages with simple events like
"the region was split into a and b", "the region was assigned to server x", and trace the
lineage of a region backwards to its parent before it came into existence.
> I'm sure there are other things we would think up that would be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message