[jira] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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: 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] [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: 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] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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: - 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] [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: - 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] [Commented] (HBASE-6974) Metric for blocked updates
[ https://issues.apache.org/jira/browse/HBASE-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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] [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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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-tabpanelfocusedCommentId=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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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.init(ColumnCount.java:47)
at
org.apache.hadoop.hbase.regionserver.ExplicitColumnTracker.init(ExplicitColumnTracker.java:69)
at
org.apache.hadoop.hbase.regionserver.ScanQueryMatcher.init(ScanQueryMatcher.java:93)
at
org.apache.hadoop.hbase.regionserver.StoreScanner.init(StoreScanner.java:65)
at
org.apache.hadoop.hbase.regionserver.Store.getScanner(Store.java:1436)
at
org.apache.hadoop.hbase.regionserver.HRegion$RegionScanner.init(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-tabpanelfocusedCommentId=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-6612) Hbase command line improvements
[ https://issues.apache.org/jira/browse/HBASE-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-6627) TestMultiVersions.testGetRowVersions is flaky
[ https://issues.apache.org/jira/browse/HBASE-6627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.init(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-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-tabpanelfocusedCommentId=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] [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] [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:
-
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] [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-tabpanelfocusedCommentId=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] [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 property namehbase.regionserver.wal.enablecompression/name valuetrue/value /property 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-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 property namehbase.regionserver.wal.enablecompression/name valuetrue/value /property 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-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 property namehbase.regionserver.wal.enablecompression/name valuetrue/value /property 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-tabpanelfocusedCommentId=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 property namehbase.regionserver.wal.enablecompression/name valuetrue/value /property 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-tabpanelfocusedCommentId=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 property namehbase.regionserver.wal.enablecompression/name valuetrue/value /property 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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] [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-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (HBASE-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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:
-
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] [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-tabpanelfocusedCommentId=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] [Commented] (HBASE-6591) checkAndPut executed/not metrics
[ https://issues.apache.org/jira/browse/HBASE-6591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
[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-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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-6518) Bytes.toBytesBinary() incorrect trailing backslash escape
[ https://issues.apache.org/jira/browse/HBASE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-6527) Make custom filters plugin
[ https://issues.apache.org/jira/browse/HBASE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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. user_home/performance_evaluation/MMddHHmmss/inputs and user_home/performance_evaluation/MMddHHmmss/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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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.init(Store.java:271)
at
[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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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(ListKeyValue) 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] [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-6431) Some FilterList Constructors break addFilter
[ https://issues.apache.org/jira/browse/HBASE-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 ListFilter rowFilters) FilterList(final Filter... rowFilters) FilterList(final Operator operator, final ListFilter rowFilters) FilterList(final Operator operator, final Filter... rowFilters) may init private ListFilter filters = new ArrayListFilter(); 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] [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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-6396) Fix NoSuchMethodError running against hadoop 2.0
[ https://issues.apache.org/jira/browse/HBASE-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=13414276page=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-6327) HLog can be null when create table
[ https://issues.apache.org/jira/browse/HBASE-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-6338) Cache Method in RPC handler
[ https://issues.apache.org/jira/browse/HBASE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-6352) Add copy method in Bytes
[ https://issues.apache.org/jira/browse/HBASE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-6302) Document how to run integration tests
[ https://issues.apache.org/jira/browse/HBASE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] [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] [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] [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-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] [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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=13286651#comment-13286651 ] Michael Drzal commented on HBASE-5609: -- @stack that seems reasonable. I'll change it to only add if not null. 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.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-v2.patch Reworked version of the patch based on Stack's comments. 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
[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-tabpanelfocusedCommentId=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
[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.patch First shot at this 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.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
