[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479192#comment-13479192 ] Michael Drzal commented on HBASE-6974: -- Sure, that is fine. Do you want me to spin a new patch? > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch, HBASE-6974-v4.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478913#comment-13478913 ] Michael Drzal commented on HBASE-6974: -- I hate naming things, and I really don't care what they are named. I did think having HighWater in the name was useful as that term is used in other places in programming/computer science and is generally well understood. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch, HBASE-6974-v4.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Attachment: HBASE-6974-v4.patch fixing a test failure > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch, HBASE-6974-v4.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Patch Available (was: Open) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch, HBASE-6974-v4.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Open (was: Patch Available) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Open (was: Patch Available) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Patch Available (was: Open) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478260#comment-13478260 ] Michael Drzal commented on HBASE-6974: -- Let me know if that works. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Attachment: HBASE-6974-v3.patch updated moving currentTimeMillis into while loop > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch, > HBASE-6974-v3.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478093#comment-13478093 ] Michael Drzal commented on HBASE-6974: -- Sure, that works as long as you are ok with missing any time used by the initial call to requestFlush. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477961#comment-13477961 ] Michael Drzal commented on HBASE-6974: -- I think I addressed all of your concerns except for the placement of currentTimeMillis. Let me know if I understood you correctly, and if so, I can make the switch. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Patch Available (was: Open) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Attachment: HBASE-6974-v2.patch Patch updated based on comments from Lars > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch, HBASE-6974-v2.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Open (was: Patch Available) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477905#comment-13477905 ] Michael Drzal commented on HBASE-6974: -- [~lhofhansl] - 1024 ms to s conversion fixed. I think I spent too much time converting bytes around, sorry - I'll add in the memstore flusher metric and post a patch in a bit - I'll look into EnvironmentEdge.currentTimeMillis - I understand what you are saying about currentTimeMillis, but let me try to restate what you said so that I am sure that we are on the same page: If I move the call to currentTimeMillis inside the while loop, that means that I will have to keep another variable off to the side to keep track of the total, plus another one to accomplish the swap. Doing this, I would call currentTimeMillis once for each time through the loop, correct? If you think that is a better way to go, I can do that. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Status: Patch Available (was: In Progress) > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6974: - Attachment: HBASE-6974.patch First shot at this. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > Attachments: HBASE-6974.patch > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-6974 started by Michael Drzal. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476960#comment-13476960 ] Michael Drzal commented on HBASE-6974: -- I'll try to get a patch up later today. > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal >Priority: Critical > Fix For: 0.94.3, 0.96.0 > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6646) Upgrade to 0.96 section in the book
[ https://issues.apache.org/jira/browse/HBASE-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476300#comment-13476300 ] Michael Drzal commented on HBASE-6646: -- It might also be good to provide actual steps for upgrading too or at least some high level guidance. I was looking for some official docs to link to, and I was surprised that there wasn't at least a high of level guide of what you should do to actually upgrade. > Upgrade to 0.96 section in the book > --- > > Key: HBASE-6646 > URL: https://issues.apache.org/jira/browse/HBASE-6646 > Project: HBase > Issue Type: Improvement > Components: documentation >Affects Versions: 0.96.0 >Reporter: Enis Soztutar >Priority: Blocker > > We should have an upgrade section in the book for 0.96. Raising this as > blocker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal reassigned HBASE-6974: Assignee: Michael Drzal > Metric for blocked updates > -- > > Key: HBASE-6974 > URL: https://issues.apache.org/jira/browse/HBASE-6974 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Michael Drzal > Fix For: 0.94.3, 0.96.0 > > > When the disc subsystem cannot keep up with a sustained high write load, a > region will eventually block updates to throttle clients. > (HRegion.checkResources). > It would be nice to have a metric for this, so that these occurrences can be > tracked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13473178#comment-13473178
]
Michael Drzal commented on HBASE-3661:
--
Done. Thanks [~saint@gmail.com]
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
> Attachments: HBASE-3661.patch
>
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-3661:
-
Status: Patch Available (was: In Progress)
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
> Attachments: HBASE-3661.patch
>
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469520#comment-13469520
]
Michael Drzal commented on HBASE-3661:
--
Review up on reviewboard, https://reviews.apache.org/r/7446/
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
> Attachments: HBASE-3661.patch
>
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-3661 started by Michael Drzal.
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
> Attachments: HBASE-3661.patch
>
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-3661:
-
Attachment: HBASE-3661.patch
Initial stab at this. Tested with mvn test and mvn test -P localTests
-Dtest=TestFromClientSide.
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
> Attachments: HBASE-3661.patch
>
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-3661) Handle empty qualifier better in shell for increments
[
https://issues.apache.org/jira/browse/HBASE-3661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal reassigned HBASE-3661:
Assignee: Michael Drzal
> Handle empty qualifier better in shell for increments
> -
>
> Key: HBASE-3661
> URL: https://issues.apache.org/jira/browse/HBASE-3661
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 0.92.0
>Reporter: Lars George
>Assignee: Michael Drzal
>Priority: Minor
>
> When trying to increment a counter using the examples, which specify no
> *explicit* qualifier you get an error:
> {code}
> hbase(main):014:0> incr 'testtable', 'cnt1', 'colfam1', 1
> ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Trying to
> contact region server 10.0.0.57:51640 for region
> testtable,,1300267113942.cd2e7925140eb414d519621e384fb654., row 'cnt1', but
> failed after 7 attempts.
> Exceptions:
> java.io.IOException: java.io.IOException: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.regionserver.ColumnCount.(ColumnCount.java:47)
> at
> org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.(ExplicitColumnTracker.java:69)
> at
> org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.(ScanQueryMatcher.java:93)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:65)
> at
> org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.(HRegion.java:2412)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.instantiateInternalScanner(HRegion.java:1185)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1171)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:1155)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getLastIncrement(HRegion.java:3087)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.incrementColumnValue(HRegion.java:3312)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.incrementColumnValue(HRegionServer.java:2570)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:309)
> at
> org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1060)
> Here is some help for this command:
> Increments a cell 'value' at specified table/row/column coordinates.
> To increment a cell value in table 't1' at row 'r1' under column
> 'c1' by 1 (can be omitted) or 10 do:
> hbase> incr 't1', 'r1', 'c1'
> hbase> incr 't1', 'r1', 'c1', 1
> hbase> incr 't1', 'r1', 'c1', 10
> {code}
> Handle this more gracefully (printing 5 stacktraces is ugly), improve the
> help to specify what is needed more clearly. Or fix the server side to
> support this, if this makes sense, and therefore never triggering this issue.
> Adding a qualifier makes it work:
> {code}
> hbase(main):015:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 1
> hbase(main):016:0> incr 'testtable', 'cnt1', 'colfam1:test', 1
> COUNTER VALUE = 2
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6634) REST API ScannerModel's protobuf converter code duplicates the setBatch call
[ https://issues.apache.org/jira/browse/HBASE-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456990#comment-13456990 ] Michael Drzal commented on HBASE-6634: -- +1 on the patch. That's really strange. > REST API ScannerModel's protobuf converter code duplicates the setBatch call > > > Key: HBASE-6634 > URL: https://issues.apache.org/jira/browse/HBASE-6634 > Project: HBase > Issue Type: Bug > Components: rest >Affects Versions: 0.94.0 >Reporter: Harsh J >Assignee: Harsh J >Priority: Trivial > Attachments: HBASE-6634.patch > > > There's a dupe call to setBatch when a scanner model object is created for > protobuf outputs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456141#comment-13456141
]
Michael Drzal commented on HBASE-6504:
--
Changed it to head -n 1 since this is the second time this came up in the
review, and I don't care either way.
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch,
> HBASE-6504-v2.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Status: Patch Available (was: Open)
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch,
> HBASE-6504-v2.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Status: Open (was: Patch Available)
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch,
> HBASE-6504-v2.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Attachment: HBASE-6504-v2.patch
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch,
> HBASE-6504-v2.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455993#comment-13455993
]
Michael Drzal commented on HBASE-6504:
--
[~tsuna] does that work for you?
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6627) TestMultiVersions.testGetRowVersions is flaky
[ https://issues.apache.org/jira/browse/HBASE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455806#comment-13455806 ] Michael Drzal commented on HBASE-6627: -- [~nkeywal] do you want to keep this around or close it and reopen if the issue comes back up? > TestMultiVersions.testGetRowVersions is flaky > - > > Key: HBASE-6627 > URL: https://issues.apache.org/jira/browse/HBASE-6627 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.96.0 > Environment: hadoop-qa mainly, seems to happen tests in parallel; > difficult to reproduce on a single test. >Reporter: nkeywal >Assignee: nkeywal > Attachments: 6627.v1.patch > > > org.apache.hadoop.hbase.TestMultiVersions.testGetRowVersions > Shutting down > Stacktrace > java.io.IOException: Shutting down > at > org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:229) > at > org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:92) > at > org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:688) > at > org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:661) > at > org.apache.hadoop.hbase.TestMultiVersions.testGetRowVersions(TestMultiVersions.java:143) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47) > at org.junit.rules.RunRules.evaluate(RunRules.java:18) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6624) [Replication]currentNbOperations should set to 0 after update the shippedOpsRate
[ https://issues.apache.org/jira/browse/HBASE-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455796#comment-13455796 ] Michael Drzal commented on HBASE-6624: -- This seems like a reasonable change. You will need to rebase the patch as HBASE-6623 got committed, so you will need to move that down a line at the very least. Unless I'm misreading the code. > [Replication]currentNbOperations should set to 0 after update the > shippedOpsRate > > > Key: HBASE-6624 > URL: https://issues.apache.org/jira/browse/HBASE-6624 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang >Assignee: terry zhang > Attachments: jira-6624.patch > > > now currentNbOperations will not reset to 0 and increase after replication > start. Now this value is used for calculate shippedOpsRate. if it is not > reset to 0 shippedOpsRate is not correct -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6612) Hbase command line improvements
[ https://issues.apache.org/jira/browse/HBASE-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455781#comment-13455781 ] Michael Drzal commented on HBASE-6612: -- [~ionignat] would HBASE-6592 address your issues? If so, it might make sense to just make this a dupe of that jira. > Hbase command line improvements > --- > > Key: HBASE-6612 > URL: https://issues.apache.org/jira/browse/HBASE-6612 > Project: HBase > Issue Type: New Feature > Components: scripts, shell >Affects Versions: 0.94.1 >Reporter: Ionut Ignatescu >Priority: Minor > > Currently, if the row key or any column value is something different than a > string, when a scan is performed via command line, the value extracted are > not decoded to a human-readable format. > It would be nice to have support to some standard data > types(long,double,etc..) or to specify some custom decoders(this would be > extremely useful for tables having composed keys). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455213#comment-13455213 ] Michael Drzal commented on HBASE-6591: -- I'm indifferent. It is really up to you. If this is a pain point for you and you feel like putting in the work to create a patch or convincing others that this is important, go for it. > checkAndPut executed/not metrics > > > Key: HBASE-6591 > URL: https://issues.apache.org/jira/browse/HBASE-6591 > Project: HBase > Issue Type: Task > Components: metrics, regionserver >Reporter: Gregory Chanan >Assignee: Gregory Chanan >Priority: Minor > Fix For: 0.96.0 > > > checkAndPut/checkAndDelete return true if the new put was executed, false > otherwise. > So clients can figure out this metric for themselves, but it would be useful > to get a look at what is happening on the cluster as a whole, across all > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455211#comment-13455211
]
Michael Drzal commented on HBASE-6504:
--
I always use the old style syntax since it is more portable. From the
coreutils info page:
For compatibility `head' also supports an obsolete option syntax
`-COUNTOPTIONS', which is recognized only if it is specified first.
COUNT is a decimal number optionally followed by a size letter (`b',
`k', `m') as in `-c', or `l' to mean count by lines, or other option
letters (`cqv'). Scripts intended for standard hosts should use `-c
COUNT' or `-n COUNT' instead. If your script must also run on hosts
that support only the obsolete syntax, it is usually simpler to avoid
`head', e.g., by using `sed 5q' instead of `head -5'.
I can change it to "head -n 1" if you would like.
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Status: Patch Available (was: Open)
Fixed this for rolling-restart.sh, start-hbase.sh, and stop-hbase.sh by using
head -1 to take the first line.
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Attachment: HBASE-6504.patch
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt, HBASE-6504.patch
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Attachment: HBASE-6504-output.txt
Shows output with/without gc args
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-6504-output.txt
>
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454974#comment-13454974 ] Michael Drzal commented on HBASE-6591: -- I don't know. You'd have to tell me what would work for your use case. If you track it at the regionserver level, you could end up with multiple regions affecting this counter. I'm not sure if you'd end up with valuable data in that case. > checkAndPut executed/not metrics > > > Key: HBASE-6591 > URL: https://issues.apache.org/jira/browse/HBASE-6591 > Project: HBase > Issue Type: Task > Components: metrics, regionserver >Reporter: Gregory Chanan >Assignee: Gregory Chanan >Priority: Minor > Fix For: 0.96.0 > > > checkAndPut/checkAndDelete return true if the new put was executed, false > otherwise. > So clients can figure out this metric for themselves, but it would be useful > to get a look at what is happening on the cluster as a whole, across all > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454885#comment-13454885 ] Michael Drzal commented on HBASE-6591: -- [~gchanan] just to make sure I understand you correctly, you would want metrics at the regionserver level along the lines of: * checkAndPutSuccesses * checkAndPutFailures * checkAndDeleteSuccesses * checkAndDeleteFailures Would they actually be helpful at the regionserver level or would you need them more granular? > checkAndPut executed/not metrics > > > Key: HBASE-6591 > URL: https://issues.apache.org/jira/browse/HBASE-6591 > Project: HBase > Issue Type: Task > Components: metrics, regionserver >Reporter: Gregory Chanan >Assignee: Gregory Chanan >Priority: Minor > Fix For: 0.96.0 > > > checkAndPut/checkAndDelete return true if the new put was executed, false > otherwise. > So clients can figure out this metric for themselves, but it would be useful > to get a look at what is happening on the cluster as a whole, across all > clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6583) Enhance Hbase load test tool to automatically create cf's if not present
[ https://issues.apache.org/jira/browse/HBASE-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6583: - Labels: noob (was: ) > Enhance Hbase load test tool to automatically create cf's if not present > > > Key: HBASE-6583 > URL: https://issues.apache.org/jira/browse/HBASE-6583 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Karthik Ranganathan > Labels: noob > > The load test tool currently disables the table and applies any changes to > the cf descriptor if any, but does not create the cf if not present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6564) HDFS space is not reclaimed when a column family is deleted
[ https://issues.apache.org/jira/browse/HBASE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454876#comment-13454876 ] Michael Drzal commented on HBASE-6564: -- [~zhi...@ebaysf.com] can we close this out? > HDFS space is not reclaimed when a column family is deleted > --- > > Key: HBASE-6564 > URL: https://issues.apache.org/jira/browse/HBASE-6564 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 0.94.1 >Reporter: J Mohamed Zahoor >Assignee: J Mohamed Zahoor >Priority: Minor > Attachments: HBASE-6564-trunk.patch, HBASE-6564-v2.patch, > HBASE-6564-v3.patch, HBASE-6564-v4.patch, HBASE-6564-v5.patch > > > When a column family of a table is deleted, the HDFS space of the column > family does not seem to be reclaimed even after a major compaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6563) s.isMajorCompaction() throws npe will cause current major Compaction checking abort
[ https://issues.apache.org/jira/browse/HBASE-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454875#comment-13454875 ] Michael Drzal commented on HBASE-6563: -- [~zhou wenjian] any response to Ted's comments? > s.isMajorCompaction() throws npe will cause current major Compaction checking > abort > --- > > Key: HBASE-6563 > URL: https://issues.apache.org/jira/browse/HBASE-6563 > Project: HBase > Issue Type: Bug > Components: regionserver >Reporter: Zhou wenjian >Assignee: Zhou wenjian > Fix For: 0.94.1 > > Attachments: HBASE-6563-trunk.patch, HBASE-6563-trunk-v2.patch, > HBASE-6563-trunk-v3.patch > > > 2012-05-05 00:49:43,265 ERROR > org.apache.hadoop.hbase.regionserver.HRegionServer$MajorCompactionChecker: > Caught exception > java.lang.NullPointerException > at > org.apache.hadoop.hbase.regionserver.Store.isMajorCompaction(Store.java:938) > at > org.apache.hadoop.hbase.regionserver.Store.isMajorCompaction(Store.java:917) > at > org.apache.hadoop.hbase.regionserver.HRegion.isMajorCompaction(HRegion.java:3250) > at > org.apache.hadoop.hbase.regionserver.HRegionServer$MajorCompactionChecker.chore(HRegionServer.java:1222) > at org.apache.hadoop.hbase.Chore.run(Chore.java:66) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6533) [replication] replication will block if WAL compress set differently in master and slave configuration
[ https://issues.apache.org/jira/browse/HBASE-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454873#comment-13454873 ] Michael Drzal commented on HBASE-6533: -- [~jdcryans] should we just close this out since the real fix is HBASE-5778? > [replication] replication will block if WAL compress set differently in > master and slave configuration > -- > > Key: HBASE-6533 > URL: https://issues.apache.org/jira/browse/HBASE-6533 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang >Assignee: terry zhang >Priority: Critical > Fix For: 0.94.3 > > Attachments: hbase-6533.patch > > > as we know in hbase 0.94.0 we have a configuration below > > hbase.regionserver.wal.enablecompression > true > > if we enable it in master cluster and disable it in slave cluster . Then > replication will not work. It will throw unwrapRemoteException again and > again in master cluster. > 2012-08-09 12:49:55,892 WARN > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Can't > replicate because of an error > on the remote cluster: > java.io.IOException: IPC server unable to read call parameters: Error in > readFields > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95) > at > org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:635) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:365) > Caused by: org.apache.hadoop.ipc.RemoteException: IPC server unable to read > call parameters: Error in readFields > at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:921) > at > org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:151) > at $Proxy13.replicateLogEntries(Unknown Source) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:616) > ... 1 more > This is because Slave cluster can not parse the hlog entry . > 2012-08-09 14:46:05,891 WARN org.apache.hadoop.ipc.HBaseServer: Unable to > read call parameters for client 10.232.98.89 > java.io.IOException: Error in readFields > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:685) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:586) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:635) > at > org.apache.hadoop.hbase.ipc.Invocation.readFields(Invocation.java:125) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.processData(HBaseServer.java:1292) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.readAndProcess(HBaseServer.java:1207) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener.doRead(HBaseServer.java:735) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.doRunLoop(HBaseServer.java:524) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.run(HBaseServer.java:499) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.EOFException > at java.io.DataInputStream.readFully(DataInputStream.java:180) > at org.apache.hadoop.hbase.KeyValue.readFields(KeyValue.java:2254) > at > org.apache.hadoop.hbase.regionserver.wal.WALEdit.readFields(WALEdit.java:146) > at > org.apache.hadoop.hbase.regionserver.wal.HLog$Entry.readFields(HLog.java:1767) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:682) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6533) [replication] replication will block if WAL compress set differently in master and slave configuration
[ https://issues.apache.org/jira/browse/HBASE-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454872#comment-13454872 ] Michael Drzal commented on HBASE-6533: -- [~terry_zhang] I've cleaned up the duplicate issues for you. > [replication] replication will block if WAL compress set differently in > master and slave configuration > -- > > Key: HBASE-6533 > URL: https://issues.apache.org/jira/browse/HBASE-6533 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang >Assignee: terry zhang >Priority: Critical > Fix For: 0.94.3 > > Attachments: hbase-6533.patch > > > as we know in hbase 0.94.0 we have a configuration below > > hbase.regionserver.wal.enablecompression > true > > if we enable it in master cluster and disable it in slave cluster . Then > replication will not work. It will throw unwrapRemoteException again and > again in master cluster. > 2012-08-09 12:49:55,892 WARN > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Can't > replicate because of an error > on the remote cluster: > java.io.IOException: IPC server unable to read call parameters: Error in > readFields > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95) > at > org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:635) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:365) > Caused by: org.apache.hadoop.ipc.RemoteException: IPC server unable to read > call parameters: Error in readFields > at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:921) > at > org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:151) > at $Proxy13.replicateLogEntries(Unknown Source) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:616) > ... 1 more > This is because Slave cluster can not parse the hlog entry . > 2012-08-09 14:46:05,891 WARN org.apache.hadoop.ipc.HBaseServer: Unable to > read call parameters for client 10.232.98.89 > java.io.IOException: Error in readFields > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:685) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:586) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:635) > at > org.apache.hadoop.hbase.ipc.Invocation.readFields(Invocation.java:125) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.processData(HBaseServer.java:1292) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.readAndProcess(HBaseServer.java:1207) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener.doRead(HBaseServer.java:735) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.doRunLoop(HBaseServer.java:524) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.run(HBaseServer.java:499) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.EOFException > at java.io.DataInputStream.readFully(DataInputStream.java:180) > at org.apache.hadoop.hbase.KeyValue.readFields(KeyValue.java:2254) > at > org.apache.hadoop.hbase.regionserver.wal.WALEdit.readFields(WALEdit.java:146) > at > org.apache.hadoop.hbase.regionserver.wal.HLog$Entry.readFields(HLog.java:1767) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:682) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6534) [replication] replication will be block if WAL compress set differently in master and slave configuration
[ https://issues.apache.org/jira/browse/HBASE-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal resolved HBASE-6534. -- Resolution: Duplicate > [replication] replication will be block if WAL compress set differently in > master and slave configuration > - > > Key: HBASE-6534 > URL: https://issues.apache.org/jira/browse/HBASE-6534 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang > > as we know in hbase 0.94.0 we have a configuration below > > hbase.regionserver.wal.enablecompression > true > > if we enable it in master cluster and disable it in slave cluster . Then > replication will not work. It will throw unwrapRemoteException again and > again in master cluster. > 2012-08-09 12:49:55,892 WARN > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Can't > replicate because of an error > on the remote cluster: > java.io.IOException: IPC server unable to read call parameters: Error in > readFields > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:513) > at > org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:95) > at > org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:79) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:635) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:365) > Caused by: org.apache.hadoop.ipc.RemoteException: IPC server unable to read > call parameters: Error in readFields > at org.apache.hadoop.hbase.ipc.HBaseClient.call(HBaseClient.java:921) > at > org.apache.hadoop.hbase.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:151) > at $Proxy13.replicateLogEntries(Unknown Source) > at > org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.shipEdits(ReplicationSource.java:616) > ... 1 more > This is because Slave cluster can not parse the hlog entry . > 2012-08-09 14:46:05,891 WARN org.apache.hadoop.ipc.HBaseServer: Unable to > read call parameters for client 10.232.98.89 > java.io.IOException: Error in readFields > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:685) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:586) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:635) > at > org.apache.hadoop.hbase.ipc.Invocation.readFields(Invocation.java:125) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.processData(HBaseServer.java:1292) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Connection.readAndProcess(HBaseServer.java:1207) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener.doRead(HBaseServer.java:735) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.doRunLoop(HBaseServer.java:524) > at > org.apache.hadoop.hbase.ipc.HBaseServer$Listener$Reader.run(HBaseServer.java:499) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.EOFException > at java.io.DataInputStream.readFully(DataInputStream.java:180) > at org.apache.hadoop.hbase.KeyValue.readFields(KeyValue.java:2254) > at > org.apache.hadoop.hbase.regionserver.wal.WALEdit.readFields(WALEdit.java:146) > at > org.apache.hadoop.hbase.regionserver.wal.HLog$Entry.readFields(HLog.java:1767) > at > org.apache.hadoop.hbase.io.HbaseObjectWritable.readObject(HbaseObjectWritable.java:682) > ... 11 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6535) [replication] replication will be block if WAL compress set differently in master and slave cluster configuration
[ https://issues.apache.org/jira/browse/HBASE-6535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal resolved HBASE-6535. -- Resolution: Duplicate > [replication] replication will be block if WAL compress set differently in > master and slave cluster configuration > - > > Key: HBASE-6535 > URL: https://issues.apache.org/jira/browse/HBASE-6535 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang > > As we know in hbase 0.94.0 we have a configuration below > > hbase.regionserver.wal.enablecompression > true > > if we enable it in master cluster and disable it in slave cluster . Then > replication will not work. It will throw unwrapRemoteException again and > again in master cluster because slave can not parse the hlog entry buffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-6536) [replication] replication will be block if WAL compress set differently in master and slave cluster configuration
[ https://issues.apache.org/jira/browse/HBASE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal resolved HBASE-6536. -- Resolution: Duplicate > [replication] replication will be block if WAL compress set differently in > master and slave cluster configuration > - > > Key: HBASE-6536 > URL: https://issues.apache.org/jira/browse/HBASE-6536 > Project: HBase > Issue Type: Bug > Components: replication >Affects Versions: 0.94.0 >Reporter: terry zhang > > As we know in hbase 0.94.0 we have a configuration below > > hbase.regionserver.wal.enablecompression > true > > if we enable it in master cluster and disable it in slave cluster . Then > replication will not work. It will throw unwrapRemoteException again and > again in master cluster because slave can not parse the hlog entry buffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6528) Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce the failure probability
[ https://issues.apache.org/jira/browse/HBASE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453981#comment-13453981 ] Michael Drzal commented on HBASE-6528: -- [~lhofhansl] I don't know enough about the test infrastructure to comment on this. Do you have any thoughts or know who would be the best person to look at this? > Raise the wait time for TestSplitLogWorker#testAcquireTaskAtStartup to reduce > the failure probability > - > > Key: HBASE-6528 > URL: https://issues.apache.org/jira/browse/HBASE-6528 > Project: HBase > Issue Type: Bug >Reporter: ShiXing >Assignee: ShiXing > Attachments: HBASE-6528-trunk-v1.patch > > > All the code for the TestSplitLogWorker, only the testAcquireTaskAtStartup > waits 100ms, other testCase wait 1000ms. The 100ms is short and sometimes > causes testAcquireTaskAtStartup failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6527) Make custom filters plugin
[ https://issues.apache.org/jira/browse/HBASE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453980#comment-13453980 ] Michael Drzal commented on HBASE-6527: -- [~zhi...@ebaysf.com] Can you or Jonathan add more detail around this or should we just close it out like [~saint@gmail.com] requests? > Make custom filters plugin > -- > > Key: HBASE-6527 > URL: https://issues.apache.org/jira/browse/HBASE-6527 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu > > More and more custom Filters are created. > We should provide plugin mechanism for these custom Filters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6518) Bytes.toBytesBinary() incorrect trailing backslash escape
[ https://issues.apache.org/jira/browse/HBASE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453977#comment-13453977 ] Michael Drzal commented on HBASE-6518: -- +1 on the patch > Bytes.toBytesBinary() incorrect trailing backslash escape > - > > Key: HBASE-6518 > URL: https://issues.apache.org/jira/browse/HBASE-6518 > Project: HBase > Issue Type: Bug > Components: util >Reporter: Tudor Scurtu >Assignee: Tudor Scurtu >Priority: Trivial > Labels: patch > Attachments: HBASE-6518.patch > > > Bytes.toBytesBinary() converts escaped strings to byte arrays. When > encountering a '\' character, it looks at the next one to see if it is an > 'x', without checking if it exists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6517) Print thread dump when a test times out
[
https://issues.apache.org/jira/browse/HBASE-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453976#comment-13453976
]
Michael Drzal commented on HBASE-6517:
--
Added a link to the hadoop jira so we can see when that gets committed.
> Print thread dump when a test times out
> ---
>
> Key: HBASE-6517
> URL: https://issues.apache.org/jira/browse/HBASE-6517
> Project: HBase
> Issue Type: Improvement
> Components: test
>Affects Versions: 0.96.0
>Reporter: Andrew Purtell
>Priority: Minor
> Labels: noob
>
> Hadoop common is adding a JUnit run listener which prints full thread dump
> into System.err when a test is failed due to timeout. See HDFS-3762.
> Suggest pulling in their {{TestTimedOutListener}} once it is committed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453971#comment-13453971
]
Michael Drzal commented on HBASE-6504:
--
I can pick this up in the next day or two. This should be a quick fix.
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Labels: noob (was: )
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Priority: Trivial
> Labels: noob
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6504) Adding GC details prevents HBase from starting in non-distributed mode
[
https://issues.apache.org/jira/browse/HBASE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Drzal updated HBASE-6504:
-
Assignee: Michael Drzal
> Adding GC details prevents HBase from starting in non-distributed mode
> --
>
> Key: HBASE-6504
> URL: https://issues.apache.org/jira/browse/HBASE-6504
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: Benoit Sigoure
>Assignee: Michael Drzal
>Priority: Trivial
> Labels: noob
>
> The {{conf/hbase-env.sh}} that ships with HBase contains a few commented out
> examples of variables that could be useful, such as adding
> {{-XX:+PrintGCDetails -XX:+PrintGCDateStamps}} to {{HBASE_OPTS}}. This has
> the annoying side effect that the JVM prints a summary of memory usage when
> it exits, and it does so on stdout:
> {code}
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed
> false
> Heap
> par new generation total 19136K, used 4908K [0x00073a20,
> 0x00073b6c, 0x00075186)
> eden space 17024K, 28% used [0x00073a20, 0x00073a6cb0a8,
> 0x00073b2a)
> from space 2112K, 0% used [0x00073b2a, 0x00073b2a,
> 0x00073b4b)
> to space 2112K, 0% used [0x00073b4b, 0x00073b4b,
> 0x00073b6c)
> concurrent mark-sweep generation total 63872K, used 0K [0x00075186,
> 0x0007556c, 0x0007f5a0)
> concurrent-mark-sweep perm gen total 21248K, used 6994K [0x0007f5a0,
> 0x0007f6ec, 0x0008)
> $ ./bin/hbase org.apache.hadoop.hbase.util.HBaseConfTool
> hbase.cluster.distributed >/dev/null
> (nothing printed)
> {code}
> And this confuses {{bin/start-hbase.sh}} when it does
> {{distMode=`$bin/hbase --config "$HBASE_CONF_DIR"
> org.apache.hadoop.hbase.util.HBaseConfTool hbase.cluster.distributed`}},
> because then the {{distMode}} variable is not just set to {{false}}, it also
> contains all this JVM spam.
> If you don't pay enough attention and realize that 3 processes are getting
> started (ZK, HM, RS) instead of just one (HM), then you end up with this
> confusing error message:
> {{Could not start ZK at requested port of 2181. ZK was started at port:
> 2182. Aborting as clients (e.g. shell) will not be able to find this ZK
> quorum.}}, which is even more puzzling because when you run {{netstat}} to
> see who owns that port, then you won't find any rogue process other than the
> one you just started.
> I'm wondering if the fix is not to just change the {{if [ "$distMode" ==
> 'false' ]}} to a {{switch $distMode case (false*)}} type of test, to work
> around this annoying JVM misfeature that pollutes stdout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6500) hbck comlaining, Exception in thread "main" java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/HBASE-6500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453968#comment-13453968 ] Michael Drzal commented on HBASE-6500: -- [~grace.huang] can we close this out as a duplicate of 6464 or are you still seeing issues? > hbck comlaining, Exception in thread "main" java.lang.NullPointerException > --- > > Key: HBASE-6500 > URL: https://issues.apache.org/jira/browse/HBASE-6500 > Project: HBase > Issue Type: Bug > Components: hbck >Affects Versions: 0.94.0 > Environment: Hadoop 0.20.205.0 > Zookeeper: zookeeper-3.3.5.jar > Hbase: hbase-0.94.0 >Reporter: liuli > > I met problem with starting Hbase: > I have 5 machines (Ubuntu) > 109.123.121.23 rsmm-master.example.com > 109.123.121.24 rsmm-slave-1.example.com > 109.123.121.25 rsmm-slave-2.example.com > 109.123.121.26 rsmm-slave-3.example.com > 109.123.121.27 rsmm-slave-4.example.com > Hadoop 0.20.205.0 > Zookeeper: zookeeper-3.3.5.jar > Hbase: hbase-0.94.0 > After starting HBase, running hbck > hduser@rsmm-master:~/hbase/bin$ ./hbase hbck > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:zookeeper.version=3.3.5-1301095, built on 03/15/2012 19:48 GMT > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:host.name=rsmm-master.example.com > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:java.version=1.6.0_33 > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:java.vendor=Sun Microsystems Inc. > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:java.home=/usr/java/jre1.6.0_33 > 28/12/12 17:13:29 INFO zookeeper.ZooKeeper: Client > environment:java.class.path=/home/hduser/hbase/conf:/usr/java/jre1.6.0_33/lib/tools.jar:/home/hduser/hbase:/home/hduser/hbase/hbase-0.94.0.jar:/home/hduser/hbase/hbase-0.94.0-tests.jar:/home/hduser/hbase/lib/activation-1.1.jar:/home/hduser/hbase/lib/asm-3.1.jar:/home/hduser/hbase/lib/avro-1.5.3.jar:/home/hduser/hbase/lib/avro-ipc-1.5.3.jar:/home/hduser/hbase/lib/commons-beanutils-1.7.0.jar:/home/hduser/hbase/lib/commons-beanutils-core-1.8.0.jar:/home/hduser/hbase/lib/commons-cli-1.2.jar:/home/hduser/hbase/lib/commons-codec-1.4.jar:/home/hduser/hbase/lib/commons-collections-3.2.1.jar:/home/hduser/hbase/lib/commons-configuration-1.6.jar:/home/hduser/hbase/lib/commons-digester-1.8.jar:/home/hduser/hbase/lib/commons-el-1.0.jar:/home/hduser/hbase/lib/commons-httpclient-3.1.jar:/home/hduser/hbase/lib/commons-io-2.1.jar:/home/hduser/hbase/lib/commons-lang-2.5.jar:/home/hduser/hbase/lib/commons-logging-1.1.1.jar:/home/hduser/hbase/lib/commons-math-2.1.jar:/home/hduser/hbase/lib/commons-net-1.4.1.jar:/home/hduser/hbase/lib/core-3.1.1.jar:/home/hduser/hbase/lib/guava-r09.jar:/home/hduser/hbase/lib/hadoop-core-0.20.205.0.jar:/home/hduser/hbase/lib/high-scale-lib-1.1.1.jar:/home/hduser/hbase/lib/httpclient-4.1.2.jar:/home/hduser/hbase/lib/httpcore-4.1.3.jar:/home/hduser/hbase/lib/jackson-core-asl-1.5.5.jar:/home/hduser/hbase/lib/jackson-jaxrs-1.5.5.jar:/home/hduser/hbase/lib/jackson-mapper-asl-1.5.5.jar:/home/hduser/hbase/lib/jackson-xc-1.5.5.jar:/home/hduser/hbase/lib/jamon-runtime-2.3.1.jar:/home/hduser/hbase/lib/jasper-compiler-5.5.23.jar:/home/hduser/hbase/lib/jasper-runtime-5.5.23.jar:/home/hduser/hbase/lib/jaxb-api-2.1.jar:/home/hduser/hbase/lib/jaxb-impl-2.1.12.jar:/home/hduser/hbase/lib/jersey-core-1.4.jar:/home/hduser/hbase/lib/jersey-json-1.4.jar:/home/hduser/hbase/lib/jersey-server-1.4.jar:/home/hduser/hbase/lib/jettison-1.1.jar:/home/hduser/hbase/lib/jetty-6.1.26.jar:/home/hduser/hbase/lib/jetty-util-6.1.26.jar:/home/hduser/hbase/lib/jruby-complete-1.6.5.jar:/home/hduser/hbase/lib/jsp-2.1-6.1.14.jar:/home/hduser/hbase/lib/jsp-api-2.1-6.1.14.jar:/home/hduser/hbase/lib/libthrift-0.8.0.jar:/home/hduser/hbase/lib/log4j-1.2.16.jar:/home/hduser/hbase/lib/netty-3.2.4.Final.jar:/home/hduser/hbase/lib/protobuf-java-2.4.0a.jar:/home/hduser/hbase/lib/servlet-api-2.5-6.1.14.jar:/home/hduser/hbase/lib/slf4j-api-1.5.8.jar:/home/hduser/hbase/lib/slf4j-log4j12-1.5.8.jar:/home/hduser/hbase/lib/snappy-java-1.0.3.2.jar:/home/hduser/hbase/lib/stax-api-1.0.1.jar:/home/hduser/hbase/lib/velocity-1.7.jar:/home/hduser/hbase/lib/xmlenc-0.52.jar:/home/hduser/hbase/lib/zookeeper-3.3.5.jar:/home/hduser/hadoop-0.20.205.0/conf:/home/hduser/hadoop-0.20.205.0/libexec/../conf:/usr/java/jre1.6.0_33/lib/tools.jar:/home/hduser/hadoop-0.20.205.0/libexec/../share/hadoop:/home/hduser/hadoop-0.20.205.0/libexec/../share/hadoop/hadoop-core-0.20.205.0.jar:/home/hduser/hadoop-0.20.205.0/libexec/../share/hadoop/lib/asm-3.2.jar:/home/hduser/hadoop-0.20.205.0/libexec/../share/hadoop/lib/aspectjrt-1.6.5.jar:/home/hduser/hadoop-0.20.205.0/libexec/../share/hadoop/lib/aspectjtools-1.6.5.jar:/home/hduser/hadoop
[jira] [Commented] (HBASE-6479) HFileReaderV1 caching the same parent META block could cause server abot when splitting
[
https://issues.apache.org/jira/browse/HBASE-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453025#comment-13453025
]
Michael Drzal commented on HBASE-6479:
--
[~zjushch] any thoughts on the test failures from HadoopQA?
> HFileReaderV1 caching the same parent META block could cause server abot when
> splitting
> ---
>
> Key: HBASE-6479
> URL: https://issues.apache.org/jira/browse/HBASE-6479
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.0
>Reporter: chunhui shen
>Assignee: chunhui shen
> Fix For: 0.96.0
>
> Attachments: HBASE-6479.patch, HBASE-6479v2.patch, test.patch
>
>
> If the hfile's version is 1 now, when splitting, two daughters would
> loadBloomfilter concurrently in the open progress. Because their META block
> is the same one(parent's META block), the following expection would be
> thrown when doing HFileReaderV1#getMetaBlock
> {code}
> java.io.IOException: Failed
> null-daughterOpener=af73f8c9a9b409531ac211a9a7f92eba
> at
> org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughters(SplitTransaction.java:367)
> at
> org.apache.hadoop.hbase.regionserver.SplitTransaction.execute(SplitTransaction.java:453)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitTransaction.testWholesomeSplit(TestSplitTransaction.java:225)
> at
> org.apache.hadoop.hbase.regionserver.TestSplitTransaction.testWholesomeSplitWithHFileV1(TestSplitTransaction.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.io.IOException: java.io.IOException:
> java.lang.RuntimeException: Cached an already cached block
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:540)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:463)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:3784)
> at
> org.apache.hadoop.hbase.regionserver.SplitTransaction.openDaughterRegion(SplitTransaction.java:506)
> at
> org.apache.hadoop.hbase.regionserver.SplitTransaction$DaughterOpener.run(SplitTransaction.java:486)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.lang.RuntimeException: Cached an already
> cached block
> at
> org.apache.hadoop.hbase.regionserver.Store.loadStoreFiles(Store.java:424)
> at org.apache.hadoop.hbase.regionserver.Store.(Store.java:271)
[jira] [Commented] (HBASE-6468) RowCounter may return incorrect result if column name is specified in command line
[ https://issues.apache.org/jira/browse/HBASE-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453016#comment-13453016 ] Michael Drzal commented on HBASE-6468: -- [~zhi...@ebaysf.com] can this be closed out? > RowCounter may return incorrect result if column name is specified in command > line > -- > > Key: HBASE-6468 > URL: https://issues.apache.org/jira/browse/HBASE-6468 > Project: HBase > Issue Type: Bug >Affects Versions: 0.90.5 >Reporter: Shrijeet Paliwal >Assignee: Shrijeet Paliwal > Fix For: 0.96.0 > > Attachments: > 0001-HBASE-6468-RowCounter-may-return-incorrect-result.patch, > 0002-HBASE-6468-RowCounter-may-return-incorrect-result.patch, > 0004-HBASE-6468-RowCounter-may-return-incorrect-result.patch, > 0005-HBASE-6468-RowCounter-may-return-incorrect-results.patch > > > The RowCounter use FirstKeyOnlyFilter regardless of whether or not the > command line argument specified a column family (or family:qualifier). > In case when no qualifier was specified as argument, the scan will > give correct result. However in the other case the scan instance may > have been set with columns other than the very first column in the > row, causing scan to get nothing as the FirstKeyOnlyFilter removes > everything else. > https://issues.apache.org/jira/browse/HBASE-6042 is related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6457) when use bulkload, hundreds of reduce write hfile, maybe create files of the same name, as a result some data loss
[ https://issues.apache.org/jira/browse/HBASE-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453007#comment-13453007 ] Michael Drzal commented on HBASE-6457: -- [~wanbin] is upgrading an option for you? > when use bulkload, hundreds of reduce write hfile, maybe create files of the > same name, as a result some data loss > --- > > Key: HBASE-6457 > URL: https://issues.apache.org/jira/browse/HBASE-6457 > Project: HBase > Issue Type: Bug > Components: mapreduce >Affects Versions: 0.90.0 >Reporter: wanbin > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6455) org.apache.hadoop.hbase.PerformanceEvaluation sets the map reduce output path as a child of input path
[ https://issues.apache.org/jira/browse/HBASE-6455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453002#comment-13453002 ] Michael Drzal commented on HBASE-6455: -- [~zhi...@ebaysf.com] can we close this out? > org.apache.hadoop.hbase.PerformanceEvaluation sets the map reduce output path > as a child of input path > -- > > Key: HBASE-6455 > URL: https://issues.apache.org/jira/browse/HBASE-6455 > Project: HBase > Issue Type: Bug > Components: performance >Affects Versions: 0.94.0, 0.96.0 >Reporter: Aditya Kishore >Assignee: Aditya Kishore >Priority: Minor > Labels: benchmark > Fix For: 0.96.0 > > Attachments: HBASE-6455_trunk.patch > > > I was the running PerformanceEvaluation test with a modified job > configuration where the job output path is created before the splits and that > unmasked the issue because the the PeInputFormat.getSplits() function expects > to find only files under the input path. > The attached patch addresses both the issues. > # Creates separate input and output path rooted under a single folder e.g. > "/performance_evaluation//inputs" and > "/performance_evaluation//outputs", and > # The PeInputFormat.getSplits(), now skips any folder found under the input > path and process only files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6441) MasterFS doesn't set scheme for internal FileSystem
[ https://issues.apache.org/jira/browse/HBASE-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451964#comment-13451964 ] Michael Drzal commented on HBASE-6441: -- [~apurtell] and [~jesse_yates] any consensus on 0.94? > MasterFS doesn't set scheme for internal FileSystem > --- > > Key: HBASE-6441 > URL: https://issues.apache.org/jira/browse/HBASE-6441 > Project: HBase > Issue Type: Bug > Components: master >Affects Versions: 0.96.0, 0.94.2 >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: 0.96.0 > > Attachments: java_HBASE-6441_v0.patch > > > FSUtils.getRootDir() just takes a configuration object, which is used to: > 1) Get the name of the root directory > 2) Create a filesystem (based on the configured scheme) > 3) Qualify the root onto the filesystem > However, the FileSystem from the master filesystem won't generate the > correctly qualified root directory under hadoop-2.0 (though it works fine on > hadoop-1.0). Seems to be an issue with the configuration parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6431) Some FilterList Constructors break addFilter
[ https://issues.apache.org/jira/browse/HBASE-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451956#comment-13451956 ] Michael Drzal commented on HBASE-6431: -- [~zhi...@ebaysf.com] can we close this out? > Some FilterList Constructors break addFilter > > > Key: HBASE-6431 > URL: https://issues.apache.org/jira/browse/HBASE-6431 > Project: HBase > Issue Type: Bug > Components: filters >Affects Versions: 0.92.1, 0.94.0 >Reporter: Alex Newman >Assignee: Alex Newman >Priority: Minor > Fix For: 0.96.0 > > Attachments: > 0001-HBASE-6431.-Some-FilterList-Constructors-break-addFi.patch, 6431-v2.txt > > > Some of the constructors for FilterList set the internal list of filters to > list types which don't support the add operation. As a result > FilterList(final List rowFilters) > FilterList(final Filter... rowFilters) > FilterList(final Operator operator, final List rowFilters) > FilterList(final Operator operator, final Filter... rowFilters) > may init private List filters = new ArrayList(); incorrectly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6430) Few modifications in section 2.4.2.1 of Apache HBase Reference Guide
[ https://issues.apache.org/jira/browse/HBASE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6430: - Labels: noob (was: ) > Few modifications in section 2.4.2.1 of Apache HBase Reference Guide > > > Key: HBASE-6430 > URL: https://issues.apache.org/jira/browse/HBASE-6430 > Project: HBase > Issue Type: Improvement >Reporter: Mohammad Tariq Iqbal >Priority: Minor > Labels: noob > Attachments: HBASE-6430.txt > > > Quite often, newbies face some issues while configuring Hbase in pseudo > distributed mode. I was no exception. I would like to propose some solutions > for these problems which worked for me. If the community finds it > appropriate, I would like to apply the patch for the same. This is the first > time I am trying to do something like this, so please pardon me if I have put > it in an appropriate manner. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6429) Filter with filterRow() returning true is incompatible with scan with limit
[ https://issues.apache.org/jira/browse/HBASE-6429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451950#comment-13451950 ] Michael Drzal commented on HBASE-6429: -- [~zhi...@ebaysf.com] can we close this out? > Filter with filterRow() returning true is incompatible with scan with limit > --- > > Key: HBASE-6429 > URL: https://issues.apache.org/jira/browse/HBASE-6429 > Project: HBase > Issue Type: Bug > Components: filters >Affects Versions: 0.96.0 >Reporter: Jason Dai >Assignee: Jie Huang > Fix For: 0.96.0 > > Attachments: hbase-6429_0_94_0.patch, hbase-6429-trunk.patch, > hbase-6429-trunk-v2.patch, hbase-6429-trunk-v3.patch, > hbase-6429-trunk-v4.patch > > > Currently if we scan with bot limit and a Filter with > filterRow(List) implemented, an IncompatibleFilterException will > be thrown. The same exception should also be thrown if the filer has its > filterRow() implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6419) PersistentMetricsTimeVaryingRate gets used for non-time-based metrics (part2 of HBASE-6220)
[ https://issues.apache.org/jira/browse/HBASE-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451947#comment-13451947 ] Michael Drzal commented on HBASE-6419: -- [~ted_yu] can we close this out? > PersistentMetricsTimeVaryingRate gets used for non-time-based metrics (part2 > of HBASE-6220) > --- > > Key: HBASE-6419 > URL: https://issues.apache.org/jira/browse/HBASE-6419 > Project: HBase > Issue Type: Improvement >Reporter: stack >Assignee: Paul Cavallaro > Attachments: ServerMetrics_HBASE_6220_Flush_Metrics.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6408) Naming and documenting of the hadoop-metrics2.properties file
[ https://issues.apache.org/jira/browse/HBASE-6408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451941#comment-13451941 ] Michael Drzal commented on HBASE-6408: -- +1 > Naming and documenting of the hadoop-metrics2.properties file > - > > Key: HBASE-6408 > URL: https://issues.apache.org/jira/browse/HBASE-6408 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Blocker > Attachments: HBASE-6408-0.patch > > > hadoop-metrics2.properties is currently where metrics2 loads it's sinks. > This file could be better named, hadoop-hbase-metrics2.properties > In addition it needs examples like the current hadoop-metrics.properties has. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6399) MetricsContext should be different between RegionServerMetrics and RegionServerDynamicMetrics
[ https://issues.apache.org/jira/browse/HBASE-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450608#comment-13450608 ] Michael Drzal commented on HBASE-6399: -- It looks like this can be closed. [~zhi...@ebaysf.com] any objections? > MetricsContext should be different between RegionServerMetrics and > RegionServerDynamicMetrics > - > > Key: HBASE-6399 > URL: https://issues.apache.org/jira/browse/HBASE-6399 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 0.94.0 >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.96.0 > > Attachments: HBASE-6399.patch, HBASE-6399v2.patch, HBASE-6399v3.patch > > > In hadoop-metrics.properties, GangliaContext is optional metrics context, I > think we will use ganglia to monitor hbase cluster generally. > However, I find a serious problem: > RegionServerDynamicMetrics will generate lots of rrd file because we would > move region or create/delete table. > Especially if table is created everyday in some applications, there are much > more and more rrd files in Gmetad Server. It will make Gmetad Server > corrupted. > IMO, MetricsContext should be different between RegionServerMetrics and > RegionServerDynamicMetrics -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6396) Fix NoSuchMethodError running against hadoop 2.0
[ https://issues.apache.org/jira/browse/HBASE-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450605#comment-13450605 ] Michael Drzal commented on HBASE-6396: -- Any objection to [~saint@gmail.com]'s suggestion of marking this won't fix? > Fix NoSuchMethodError running against hadoop 2.0 > > > Key: HBASE-6396 > URL: https://issues.apache.org/jira/browse/HBASE-6396 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.0 >Reporter: Zhihong Ted Yu >Assignee: Zhihong Ted Yu > Labels: hadoop-2.0 > Fix For: 0.96.0 > > Attachments: 6396-v2.txt > > > HADOOP-8350 changed the signature of NetUtils.getInputStream() > This leads to NoSuchMethodError in HBaseClient$Connection.setupIOstreams(). > See > https://issues.apache.org/jira/browse/HADOOP-8350?focusedCommentId=13414276&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13414276 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6366) Eviction on close should be delayed until next eviction to improve performance.
[ https://issues.apache.org/jira/browse/HBASE-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13450573#comment-13450573 ] Michael Drzal commented on HBASE-6366: -- [~michalgr] any additional details on this? > Eviction on close should be delayed until next eviction to improve > performance. > --- > > Key: HBASE-6366 > URL: https://issues.apache.org/jira/browse/HBASE-6366 > Project: HBase > Issue Type: Improvement >Reporter: Michal Gregorczyk >Assignee: Michal Gregorczyk > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6324) Direct API calls from embedded Thrift server to regionserver
[ https://issues.apache.org/jira/browse/HBASE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449925#comment-13449925 ] Michael Drzal commented on HBASE-6324: -- [~stack] thanks for the explanation. That makes sense. > Direct API calls from embedded Thrift server to regionserver > > > Key: HBASE-6324 > URL: https://issues.apache.org/jira/browse/HBASE-6324 > Project: HBase > Issue Type: Improvement >Reporter: Mikhail Bautin >Assignee: Mikhail Bautin > > When handling Thrift calls in the regionserver we should not go through RPC > to talk to the local regionserver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6352) Add copy method in Bytes
[ https://issues.apache.org/jira/browse/HBASE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449645#comment-13449645 ] Michael Drzal commented on HBASE-6352: -- Can this be closed? > Add copy method in Bytes > > > Key: HBASE-6352 > URL: https://issues.apache.org/jira/browse/HBASE-6352 > Project: HBase > Issue Type: Improvement > Components: util >Affects Versions: 0.94.0 >Reporter: Jean-Marc Spaggiari >Priority: Minor > Labels: Bytes, Util > Attachments: HBASE_JIRA_6352.patch, HBASE_JIRA_6352_v2.patch, > HBASE_JIRA_6352_v3.patch, HBASE_JIRA_6352_v4.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Having a "copy" method into Bytes might be nice to reduce client code size > and improve readability. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6338) Cache Method in RPC handler
[ https://issues.apache.org/jira/browse/HBASE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449634#comment-13449634 ] Michael Drzal commented on HBASE-6338: -- [~aoxiang] this seems to have stalled. > Cache Method in RPC handler > --- > > Key: HBASE-6338 > URL: https://issues.apache.org/jira/browse/HBASE-6338 > Project: HBase > Issue Type: Improvement >Reporter: binlijin > Attachments: HBASE-6338-90-2.patch, HBASE-6338-90.patch, > HBASE-6338-92-2.patch, HBASE-6338-92.patch, HBASE-6338-94-2.patch, > HBASE-6338-94.patch, HBASE-6338-trunk-2.patch, HBASE-6338-trunk.patch > > > Every call in rpc handler a Method will be created, if we cache the method > will improve a little. > I test with 0.90, Average Class.getMethod(String name, Class... > parameterTypes) cost 4780 ns , if we cache it cost 2620 ns. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6327) HLog can be null when create table
[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449631#comment-13449631 ] Michael Drzal commented on HBASE-6327: -- I'm confused about the state of this jira. [~zhi...@ebaysf.com] said that he added in the patch, but the state is patch available with comments after the fix. Can this be closed out? > HLog can be null when create table > -- > > Key: HBASE-6327 > URL: https://issues.apache.org/jira/browse/HBASE-6327 > Project: HBase > Issue Type: Bug >Reporter: ShiXing >Assignee: ShiXing > Fix For: 0.96.0 > > Attachments: 6327.txt, createTableFailedMaster.log, > HBASE-6327-trunk-V1.patch > > > As HBASE-4010 discussed, the HLog can be null. > We have meet createTable failed because the no use hlog. > When createHReagion, the HLog.LogSyncer is run sync(), in under layer it call > the DFSClient.DFSOutputStream.sync(). > Then the hlog.closeAndDelete() was called，firstly the HLog.close() will > interrupt the LogSyncer, and interrupt DFSClient.DFSOutputStream.sync().The > DFSClient.DFSOutputStream will store the exception and throw it when we > called DFSClient.close(). > The HLog.close() call the writer.close()/DFSClient.close() after interrupt > the LogSyncer. And there is no catch exception for the close(). > So the Master throw exception to the client. There is no need to throw this > exception, further， the hlog is no use. > Our cluster is 0.90, the logs is attached, after "closing hlog writer", there > is no log for the createTable(). > The trunk and 0.92, 0.94, we used just one hlog, and if the exception > happends, the client will got createTable failed, but indeed ,we expect all > the regions for the table can also be assigned. > I will give the patch for this later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6324) Direct API calls from embedded Thrift server to regionserver
[ https://issues.apache.org/jira/browse/HBASE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449629#comment-13449629 ] Michael Drzal commented on HBASE-6324: -- Looking at the facebook review, it appears that this mostly done. [~mikhail] what else needs to get done to close this out here? > Direct API calls from embedded Thrift server to regionserver > > > Key: HBASE-6324 > URL: https://issues.apache.org/jira/browse/HBASE-6324 > Project: HBase > Issue Type: Improvement >Reporter: Mikhail Bautin >Assignee: Mikhail Bautin > > When handling Thrift calls in the regionserver we should not go through RPC > to talk to the local regionserver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6302) Document how to run integration tests
[ https://issues.apache.org/jira/browse/HBASE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448755#comment-13448755 ] Michael Drzal commented on HBASE-6302: -- Patch looks good, with the exception of the points that Andrew made. > Document how to run integration tests > - > > Key: HBASE-6302 > URL: https://issues.apache.org/jira/browse/HBASE-6302 > Project: HBase > Issue Type: Sub-task > Components: documentation >Reporter: stack >Assignee: Enis Soztutar >Priority: Blocker > Fix For: 0.96.0 > > Attachments: HBASE-6302_v1.patch > > > HBASE-6203 has attached the old IT doc with some mods. When we figure how > ITs are to be run, update it and apply the documentation under this issue. > Making a blocker against 0.96. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6288) In hbase-daemons.sh, description of the default backup-master file path is wrong
[
https://issues.apache.org/jira/browse/HBASE-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448732#comment-13448732
]
Michael Drzal commented on HBASE-6288:
--
+1 looks good [~benkimkimben]
> In hbase-daemons.sh, description of the default backup-master file path is
> wrong
>
>
> Key: HBASE-6288
> URL: https://issues.apache.org/jira/browse/HBASE-6288
> Project: HBase
> Issue Type: Task
> Components: master, scripts, shell
>Affects Versions: 0.92.0, 0.92.1, 0.94.0
>Reporter: Benjamin Kim
> Attachments: HBASE-6288-92-1.patch, HBASE-6288-92.patch,
> HBASE-6288-94.patch, HBASE-6288-trunk.patch
>
>
> In hbase-daemons.sh, description of the default backup-master file path is
> wrong
> {code}
> # HBASE_BACKUP_MASTERS File naming remote hosts.
> # Default is ${HADOOP_CONF_DIR}/backup-masters
> {code}
> it says the default backup-masters file path is at a hadoop-conf-dir, but
> shouldn't this be HBASE_CONF_DIR?
> also adding following lines to conf/hbase-env.sh would be helpful
> {code}
> # File naming hosts on which backup HMaster will run.
> $HBASE_HOME/conf/backup-masters by default.
> export HBASE_BACKUP_MASTERS=${HBASE_HOME}/conf/backup-masters
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6286) Upgrade maven-compiler-plugin to 2.5.1
[ https://issues.apache.org/jira/browse/HBASE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448727#comment-13448727 ] Michael Drzal commented on HBASE-6286: -- +1 seems like a win to me > Upgrade maven-compiler-plugin to 2.5.1 > -- > > Key: HBASE-6286 > URL: https://issues.apache.org/jira/browse/HBASE-6286 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Minor > Attachments: HBASE-6286.patch > > > time mvn -PlocalTests clean install -DskipTests > With 2.5.1: > |user|1m35.634s|1m31.178s|1m31.366s| > |sys|0m06.540s|0m05.376s|0m05.488s| > With 2.0.2 (current): > |user|2m01.168s|1m54.027s|1m57.799s| > |sys|0m05.896s|0m05.912s|0m06.032s| -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6264) Typos in the book documentation
[ https://issues.apache.org/jira/browse/HBASE-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445164#comment-13445164 ] Michael Drzal commented on HBASE-6264: -- [~dmeil] what needs to be done to push this along? > Typos in the book documentation > --- > > Key: HBASE-6264 > URL: https://issues.apache.org/jira/browse/HBASE-6264 > Project: HBase > Issue Type: Improvement > Components: documentation >Affects Versions: 0.94.0 >Reporter: Jean-Marc Spaggiari >Priority: Minor > Labels: documentation > Attachments: typo_HBASE_6264.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > In section 6.9: http://hbase.apache.org/book/secondary.indexes.html > In section 9.2: http://hbase.apache.org/book/arch.catalog.html > There is "are are" twice. I'm not 100% sure what's the best way to propose a > fix, so I have included the patch below. If that's fine, I will probably > propose some other corrections. > JM > Index: branches/0.94/src/docbkx/book.xml > === > --- branches/0.94/src/docbkx/book.xml (révision 1352979) > +++ branches/0.94/src/docbkx/book.xml (copie de travail) > @@ -828,7 +828,7 @@ >Secondary Indexes and Alternate Query Paths > >This section could also be titled "what if my table rowkey looks > like this but I also want to query my table like > that." > - A common example on the dist-list is where a row-key is of the format > "user-timestamp" but there are are reporting requirements on activity across > users for certain > + A common example on the dist-list is where a row-key is of the format > "user-timestamp" but there are reporting requirements on activity across > users for certain >time ranges. Thus, selecting by user is easy because it is in the lead > position of the key, but time is not. > >There is no single answer on the best way to handle this because it > depends on... > @@ -1324,7 +1324,7 @@ > > >Catalog Tables > - The catalog tables -ROOT- and .META. exist as HBase tables. > They are are filtered out > + The catalog tables -ROOT- and .META. exist as HBase tables. > They are filtered out > of the HBase shell's list command, but they are in fact > tables just like any other. > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6257) Avoid unnecessary flush & compact on Meta in admin.rb.
[ https://issues.apache.org/jira/browse/HBASE-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445150#comment-13445150 ] Michael Drzal commented on HBASE-6257: -- +1 > Avoid unnecessary flush & compact on Meta in admin.rb. > -- > > Key: HBASE-6257 > URL: https://issues.apache.org/jira/browse/HBASE-6257 > Project: HBase > Issue Type: Sub-task > Components: security, shell >Affects Versions: 0.94.0, 0.96.0, 0.94.1 >Reporter: Laxman >Assignee: Laxman > Labels: security > Attachments: HBASE-6257.patch > > > Discussed on dev list. > When we drop a table or a group of tables via shell it flushes and triggers > major compaction on .META. > drop requires a 'C' on table > flush & compact requires 'A' on meta table > So, drop will fail even if a user has sufficient permissions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6249) Apply ACLs to new bulk load hooks
[ https://issues.apache.org/jira/browse/HBASE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445147#comment-13445147 ] Michael Drzal commented on HBASE-6249: -- Should we just mark this as a dup? > Apply ACLs to new bulk load hooks > - > > Key: HBASE-6249 > URL: https://issues.apache.org/jira/browse/HBASE-6249 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Francis Liu > > HBASE-6224 adds coprocessor hooks for bulk loading. This should require table > WRITE permission. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6234) Move simple KeyValue tests to hbase-common module
[ https://issues.apache.org/jira/browse/HBASE-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445144#comment-13445144 ] Michael Drzal commented on HBASE-6234: -- [~mcorgan] can you hit the submit patch button to get this going? It looks like it is stalled. Seems like a good fix to me. > Move simple KeyValue tests to hbase-common module > - > > Key: HBASE-6234 > URL: https://issues.apache.org/jira/browse/HBASE-6234 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.96.0 >Reporter: Matt Corgan >Assignee: Matt Corgan > Attachments: HBASE-6234-v1.patch > > > TestKeyValue, LoadTestKVGenerator, and TestLoadTestKVGenerator should move up > to hbase-common. This brings MD5Hash up as a dependency as well. > To play well with Maven as discussed in HBASE-6162, I moved > LoadTestKVGenerator from the src/test folder to src/main folder so that tests > in other modules can see it. A couple other files' import statements were > affected by this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6231) Minor Typos in HBase Book
[ https://issues.apache.org/jira/browse/HBASE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445138#comment-13445138 ] Michael Drzal commented on HBASE-6231: -- [~dmeil] does Jean-Marc just need to hit submit patch on this one? > Minor Typos in HBase Book > - > > Key: HBASE-6231 > URL: https://issues.apache.org/jira/browse/HBASE-6231 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Chad Gorshing >Priority: Trivial > Labels: documentation > Attachments: hbase_JIRA_62.31.patch > > > I have other minor things like this to submit, what is the best method to > submit these? > http://hbase.apache.org/book/important_configurations.html#balancer_config > Under 2.8.3.1 "The balancer is periodic operation run on the master to > redistribute regions on the cluster." - I think this reads a little better - > "The balancer is a periodic operation which is ran on the master to > redistribute regions on the cluster." > http://hbase.apache.org/book/master.html#master.processes.loadbalancer > Under 9.5.4.1 "Periodically, and when there are not any regions in > transition, a load balancer will run and move regions around to balance > cluster load." - I think this reads a little better - "Periodically, and when > there are not any regions in transition, a load balancer will run and move > regions around to balance the cluster's load." > http://hbase.apache.org/book/node.management.html > Under 14.3.2 "Effect repairs if inconsistent." I believe this should be > "Expect repairs if inconsistent" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6192) Document ACL matrix in the book
[ https://issues.apache.org/jira/browse/HBASE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444045#comment-13444045 ] Michael Drzal commented on HBASE-6192: -- [~saint@gmail.com] did you ever get a chance to look at the updated matrix? > Document ACL matrix in the book > --- > > Key: HBASE-6192 > URL: https://issues.apache.org/jira/browse/HBASE-6192 > Project: HBase > Issue Type: Sub-task > Components: documentation, security >Affects Versions: 0.96.0, 0.94.1 >Reporter: Enis Soztutar >Assignee: Laxman > Labels: documentaion, security > Attachments: HBase Security-ACL Matrix.pdf, HBase Security-ACL > Matrix.pdf, HBase Security-ACL Matrix.pdf, HBase Security-ACL Matrix.xls, > HBase Security-ACL Matrix.xls, HBase Security-ACL Matrix.xls > > > We have an excellent matrix at > https://issues.apache.org/jira/secure/attachment/12531252/Security-ACL%20Matrix.pdf > for ACL. Once the changes are done, we can adapt that and put it in the > book, also add some more documentation about the new authorization features. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6176) Take down the stargate reset doc or add pointer to manual documentation
[ https://issues.apache.org/jira/browse/HBASE-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444039#comment-13444039 ] Michael Drzal commented on HBASE-6176: -- [~andrew.purt...@gmail.com] did you ever get a chance to try this again? > Take down the stargate reset doc or add pointer to manual documentation > --- > > Key: HBASE-6176 > URL: https://issues.apache.org/jira/browse/HBASE-6176 > Project: HBase > Issue Type: Bug >Reporter: stack > > Its confusing folks having it still up at > http://wiki.apache.org/hadoop/Hbase/Stargate (Just tripped over a confused > individual in irc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6159) truncate leaks ZK connection in HBase shell
[
https://issues.apache.org/jira/browse/HBASE-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444035#comment-13444035
]
Michael Drzal commented on HBASE-6159:
--
+1 on this. Anything else that needs to happen?
> truncate leaks ZK connection in HBase shell
> ---
>
> Key: HBASE-6159
> URL: https://issues.apache.org/jira/browse/HBASE-6159
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 0.90.6
>Reporter: Richard Ding
>Assignee: Richard Ding
>Priority: Minor
> Attachments: 6159.txt, 6159.txt
>
>
> ZK connection count always goes up by one when running shell command:
> {code}
> hbase(main):001:0> truncate 'table'
> {code}
> This can be fixed with the change in admin.rb:
> {code}
> - h_table = org.apache.hadoop.hbase.client.HTable.new(table_name)
> - table_description = h_table.getTableDescriptor()
> + table_description = @admin.getTableDescriptor(table_name.to_java_bytes)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6128) Use weights instead of block counts in DoubleBlockCache with CacheBuilder
[ https://issues.apache.org/jira/browse/HBASE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443176#comment-13443176 ] Michael Drzal commented on HBASE-6128: -- [~jdcryans] could you add a bit more detail on this? We are looking for some work to pickup, and this might be of interest. > Use weights instead of block counts in DoubleBlockCache with CacheBuilder > - > > Key: HBASE-6128 > URL: https://issues.apache.org/jira/browse/HBASE-6128 > Project: HBase > Issue Type: Bug >Reporter: Jean-Daniel Cryans >Priority: Minor > > Thanks to HBASE-5739 we can now specify a max weight instead of a maximum > number of blocks in the DoubleBlockCache. This will give a more accurate > control over its memory usage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6119) Region server logs its own address at the end of getMaster()
[
https://issues.apache.org/jira/browse/HBASE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443170#comment-13443170
]
Michael Drzal commented on HBASE-6119:
--
[~zhi...@ebaysf.com] going through old bugs. Can this be closed?
> Region server logs its own address at the end of getMaster()
>
>
> Key: HBASE-6119
> URL: https://issues.apache.org/jira/browse/HBASE-6119
> Project: HBase
> Issue Type: Bug
>Reporter: Zhihong Ted Yu
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: 6119-trunk.txt
>
>
> I saw the following in region server log where a.ebay.com is region server
> itself:
> {code}
> 2012-05-28 08:56:35,315 INFO
> org.apache.hadoop.hbase.regionserver.HRegionServer: Connected to master at
> a.ebay.com/10.115.13.20:60020
> {code}
> We should be logging the address of master
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6080) site.xml - adding ReviewBoard to main page left-hand nav
[ https://issues.apache.org/jira/browse/HBASE-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442446#comment-13442446 ] Michael Drzal commented on HBASE-6080: -- [~dmeil] looking over old bugs, and I saw this one. It looks like the link already exists. Any reason this can't be closed out? > site.xml - adding ReviewBoard to main page left-hand nav > > > Key: HBASE-6080 > URL: https://issues.apache.org/jira/browse/HBASE-6080 > Project: HBase > Issue Type: Improvement >Reporter: Doug Meil >Assignee: Doug Meil >Priority: Trivial > Attachments: src_hbase_6080.patch > > > By request, adding ReviewBoard to left-hand nav on website -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6582) Code generation does run under m2eclipse
[ https://issues.apache.org/jira/browse/HBASE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438465#comment-13438465 ] Michael Drzal commented on HBASE-6582: -- I'm fine with just trunk. Thanks. > Code generation does run under m2eclipse > > > Key: HBASE-6582 > URL: https://issues.apache.org/jira/browse/HBASE-6582 > Project: HBase > Issue Type: Bug >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Fix For: 0.96.0 > > Attachments: HBASE-6582.patch > > > When going through the instructions on > http://hbase.apache.org/book/ides.html, the build will fail in eclipse > because none of the sources are generated. After looking at our pom and > reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling > m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6582) Code generation does run under m2eclipse
[ https://issues.apache.org/jira/browse/HBASE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6582: - Status: Patch Available (was: Open) > Code generation does run under m2eclipse > > > Key: HBASE-6582 > URL: https://issues.apache.org/jira/browse/HBASE-6582 > Project: HBase > Issue Type: Bug >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-6582.patch > > > When going through the instructions on > http://hbase.apache.org/book/ides.html, the build will fail in eclipse > because none of the sources are generated. After looking at our pom and > reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling > m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6582) Code generation does run under m2eclipse
[ https://issues.apache.org/jira/browse/HBASE-6582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-6582: - Attachment: HBASE-6582.patch Allows code generation to run from m2eclipse. > Code generation does run under m2eclipse > > > Key: HBASE-6582 > URL: https://issues.apache.org/jira/browse/HBASE-6582 > Project: HBase > Issue Type: Bug >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-6582.patch > > > When going through the instructions on > http://hbase.apache.org/book/ides.html, the build will fail in eclipse > because none of the sources are generated. After looking at our pom and > reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling > m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6582) Code generation does run under m2eclipse
Michael Drzal created HBASE-6582: Summary: Code generation does run under m2eclipse Key: HBASE-6582 URL: https://issues.apache.org/jira/browse/HBASE-6582 Project: HBase Issue Type: Bug Reporter: Michael Drzal Assignee: Michael Drzal Priority: Minor When going through the instructions on http://hbase.apache.org/book/ides.html, the build will fail in eclipse because none of the sources are generated. After looking at our pom and reading http://wiki.eclipse.org/M2E_compatible_maven_plugins, we are telling m2eclipse to ignore the avro and jamon plugins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5609) Add the ability to pass additional information for slow query logging
[ https://issues.apache.org/jira/browse/HBASE-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289465#comment-13289465 ] Michael Drzal commented on HBASE-5609: -- Created HBASE-6163 and linked it back to this for the toMap work. > Add the ability to pass additional information for slow query logging > - > > Key: HBASE-5609 > URL: https://issues.apache.org/jira/browse/HBASE-5609 > Project: HBase > Issue Type: New Feature > Components: client, ipc >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-5609-v2.patch, HBASE-5609-v3.patch, > HBASE-5609.patch > > > HBase-4117 added the ability to log information about queries that returned > too much data or ran for too long. There is some information written as a > fingerprint that can be used to tell what table/column families/... are > affected. I would like to extend this functionality to allow the client to > insert an identifier into the operation that gets output in the log. The > idea behind this would be that if there were N places in the client > application that touched a given table in a certain way, you could quickly > narrow things down by inserting a className:functionName or similar > identifier. I'm fully willing to go back on this if people think that it > isn't a problem in real life and it would just add complexity to the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-6163) Abstract out common functionality from toMap in client operations
Michael Drzal created HBASE-6163: Summary: Abstract out common functionality from toMap in client operations Key: HBASE-6163 URL: https://issues.apache.org/jira/browse/HBASE-6163 Project: HBase Issue Type: Improvement Components: client Reporter: Michael Drzal Assignee: Michael Drzal Priority: Minor There is a lot of commonality in the implementations of toMap in the various client operations. The common portions really need to be abstracted away into a common place so that the children only do the work that is specific to them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5609) Add the ability to pass additional information for slow query logging
[ https://issues.apache.org/jira/browse/HBASE-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-5609: - Release Note: Added the ability to add identifiers to client operations. These identifiers will be output with slow query logging. The could be used to identify the piece of code that initiated the operation. This could be anything from a module name to a class.method with a line number. Status: Patch Available (was: Open) > Add the ability to pass additional information for slow query logging > - > > Key: HBASE-5609 > URL: https://issues.apache.org/jira/browse/HBASE-5609 > Project: HBase > Issue Type: New Feature > Components: client, ipc >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-5609-v2.patch, HBASE-5609-v3.patch, > HBASE-5609.patch > > > HBase-4117 added the ability to log information about queries that returned > too much data or ran for too long. There is some information written as a > fingerprint that can be used to tell what table/column families/... are > affected. I would like to extend this functionality to allow the client to > insert an identifier into the operation that gets output in the log. The > idea behind this would be that if there were N places in the client > application that touched a given table in a certain way, you could quickly > narrow things down by inserting a className:functionName or similar > identifier. I'm fully willing to go back on this if people think that it > isn't a problem in real life and it would just add complexity to the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5609) Add the ability to pass additional information for slow query logging
[ https://issues.apache.org/jira/browse/HBASE-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Drzal updated HBASE-5609: - Attachment: HBASE-5609-v3.patch Added a couple of whitespace fixes > Add the ability to pass additional information for slow query logging > - > > Key: HBASE-5609 > URL: https://issues.apache.org/jira/browse/HBASE-5609 > Project: HBase > Issue Type: New Feature > Components: client, ipc >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-5609-v2.patch, HBASE-5609-v3.patch, > HBASE-5609.patch > > > HBase-4117 added the ability to log information about queries that returned > too much data or ran for too long. There is some information written as a > fingerprint that can be used to tell what table/column families/... are > affected. I would like to extend this functionality to allow the client to > insert an identifier into the operation that gets output in the log. The > idea behind this would be that if there were N places in the client > application that touched a given table in a certain way, you could quickly > narrow things down by inserting a className:functionName or similar > identifier. I'm fully willing to go back on this if people think that it > isn't a problem in real life and it would just add complexity to the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5609) Add the ability to pass additional information for slow query logging
[ https://issues.apache.org/jira/browse/HBASE-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286790#comment-13286790 ] Michael Drzal commented on HBASE-5609: -- Yep, just looked at Jesse's comments. I think the new patch takes care of them. I'll verify with him. > Add the ability to pass additional information for slow query logging > - > > Key: HBASE-5609 > URL: https://issues.apache.org/jira/browse/HBASE-5609 > Project: HBase > Issue Type: New Feature > Components: client, ipc >Reporter: Michael Drzal >Assignee: Michael Drzal >Priority: Minor > Attachments: HBASE-5609-v2.patch, HBASE-5609.patch > > > HBase-4117 added the ability to log information about queries that returned > too much data or ran for too long. There is some information written as a > fingerprint that can be used to tell what table/column families/... are > affected. I would like to extend this functionality to allow the client to > insert an identifier into the operation that gets output in the log. The > idea behind this would be that if there were N places in the client > application that touched a given table in a certain way, you could quickly > narrow things down by inserting a className:functionName or similar > identifier. I'm fully willing to go back on this if people think that it > isn't a problem in real life and it would just add complexity to the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
