[jira] [Commented] (HBASE-11656) Document how to script snapshots
[
https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092506#comment-14092506
]
Matteo Bertozzi commented on HBASE-11656:
-
{quote}If the snapshot is successful, the command will return 0. Otherwise, it
will return a non-zero value.{quote}
That is 100% not correct. If the client hit the operation timeout or lose the
connection with the server you'll get a failure (non-zero value), which you are
not able to interpret. The snapshot may be created or may not be created.
(why do we need a specific example for snapshots shouldn't a generic example of
scripting be provided with HBASE-11655?)
> Document how to script snapshots
>
>
> Key: HBASE-11656
> URL: https://issues.apache.org/jira/browse/HBASE-11656
> Project: HBase
> Issue Type: Sub-task
> Components: documentation, shell
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Attachments: HBASE-11656.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-10247) Client promises about timestamps
[ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-10247: -- Attachment: 10247.txt *Partial* patch. Completely untested, and not even 1/3 finished. Just want to park it here. Will probably finish it tomorrow or the day after. So far has: * the new table attribute * old tables are "grandfathered in" as MIXED * new tables default to SERVER_TS * can be set/viewed via shell Missing: * nothing is enforced, yet. * transitions are not yet restricted * no tests, yet. > Client promises about timestamps > > > Key: HBASE-10247 > URL: https://issues.apache.org/jira/browse/HBASE-10247 > Project: HBase > Issue Type: Brainstorming >Reporter: Lars Hofhansl >Priority: Minor > Attachments: 10247.txt > > > This is to start a discussion about timestamp promises declared per table of > CF. > For example if a client promises only monotonically increasing timestamps (or > no custom set timestamps) and VERSIONS=1, we can aggressively and easily > remove old versions of the same row/fam/col from the memstore before we > flush, just by supplying a comparator that ignores the timestamp (i.e. two KV > just differing by TS would be considered equal). > That would increase the performance of counters significantly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11670) Build PDF of Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092502#comment-14092502 ] Misty Stanley-Jones commented on HBASE-11670: - Blergh. This is not fun. Looks like it will require some refactoring of the XML to make the PDF look nice. I will work on it bit by bit in my spare time. > Build PDF of Ref Guide > -- > > Key: HBASE-11670 > URL: https://issues.apache.org/jira/browse/HBASE-11670 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11716) LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
[
https://issues.apache.org/jira/browse/HBASE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-11716:
---
Fix Version/s: 0.98.6
> LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
>
>
> Key: HBASE-11716
> URL: https://issues.apache.org/jira/browse/HBASE-11716
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.5
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Labels: IntegrationTest
> Fix For: 0.98.6
>
> Attachments: HBASE-11716.patch
>
>
> {code}
> public Mutation beforeMutate(long rowkeyBase, Mutation m) throws
> IOException {
> if (!(m instanceof Delete)) {
> m.setCellVisibility(new CellVisibility(this.visibilityExps[(int)
> rowkeyBase
> % this.visibilityExps.length]));
> }
> return m;
> }
> {code}
> Now we have delete CellVisibility matching and so we should add
> CellVisibility for Mutations also. Just removing the if check part will solve
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11716) LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
[
https://issues.apache.org/jira/browse/HBASE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092454#comment-14092454
]
ramkrishna.s.vasudevan commented on HBASE-11716:
+1 on change.
> LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
>
>
> Key: HBASE-11716
> URL: https://issues.apache.org/jira/browse/HBASE-11716
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.5
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Labels: IntegrationTest
> Attachments: HBASE-11716.patch
>
>
> {code}
> public Mutation beforeMutate(long rowkeyBase, Mutation m) throws
> IOException {
> if (!(m instanceof Delete)) {
> m.setCellVisibility(new CellVisibility(this.visibilityExps[(int)
> rowkeyBase
> % this.visibilityExps.length]));
> }
> return m;
> }
> {code}
> Now we have delete CellVisibility matching and so we should add
> CellVisibility for Mutations also. Just removing the if check part will solve
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11716) LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
[
https://issues.apache.org/jira/browse/HBASE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092450#comment-14092450
]
ramkrishna.s.vasudevan commented on HBASE-11716:
Added this change in one the IT that was created using LTT. I will raise a
JIRA to add that IT for visibility labels along with deletes that uses the LTT
tool.
> LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
>
>
> Key: HBASE-11716
> URL: https://issues.apache.org/jira/browse/HBASE-11716
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.5
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Labels: IntegrationTest
> Attachments: HBASE-11716.patch
>
>
> {code}
> public Mutation beforeMutate(long rowkeyBase, Mutation m) throws
> IOException {
> if (!(m instanceof Delete)) {
> m.setCellVisibility(new CellVisibility(this.visibilityExps[(int)
> rowkeyBase
> % this.visibilityExps.length]));
> }
> return m;
> }
> {code}
> Now we have delete CellVisibility matching and so we should add
> CellVisibility for Mutations also. Just removing the if check part will solve
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11716) LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
[
https://issues.apache.org/jira/browse/HBASE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-11716:
---
Attachment: HBASE-11716.patch
> LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
>
>
> Key: HBASE-11716
> URL: https://issues.apache.org/jira/browse/HBASE-11716
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.5
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Labels: IntegrationTest
> Attachments: HBASE-11716.patch
>
>
> {code}
> public Mutation beforeMutate(long rowkeyBase, Mutation m) throws
> IOException {
> if (!(m instanceof Delete)) {
> m.setCellVisibility(new CellVisibility(this.visibilityExps[(int)
> rowkeyBase
> % this.visibilityExps.length]));
> }
> return m;
> }
> {code}
> Now we have delete CellVisibility matching and so we should add
> CellVisibility for Mutations also. Just removing the if check part will solve
> the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (HBASE-11716) LoadTestDataGeneratorWithVisibilityLabels should handle Delete mutations
Anoop Sam John created HBASE-11716:
--
Summary: LoadTestDataGeneratorWithVisibilityLabels should handle
Delete mutations
Key: HBASE-11716
URL: https://issues.apache.org/jira/browse/HBASE-11716
Project: HBase
Issue Type: Bug
Affects Versions: 0.98.5
Reporter: Anoop Sam John
Assignee: Anoop Sam John
{code}
public Mutation beforeMutate(long rowkeyBase, Mutation m) throws IOException {
if (!(m instanceof Delete)) {
m.setCellVisibility(new CellVisibility(this.visibilityExps[(int)
rowkeyBase
% this.visibilityExps.length]));
}
return m;
}
{code}
Now we have delete CellVisibility matching and so we should add CellVisibility
for Mutations also. Just removing the if check part will solve the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[
https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Qiang Tian updated HBASE-11714:
---
Description:
Discussed on the user@hbase mailing list
(http://markmail.org/thread/w3cqjxwo2smkn2jw)
{quote}
"Recently switched from 0.94 and 0.98, and finding that periodically things
are having issues - lots of retry exceptions" :
{quote}
client log:
{quote}
2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158,
table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops,
last exception: java.net.SocketTimeoutException: Call to
ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed
because java.net.SocketTimeoutException: 2000 millis timeout while waiting
for channel to be ready for read. ch :
java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014
remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on
ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking
started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500
ops.
{quote}
analysis:
there are 2 methods in RpcRetryingCaller: callWithRetries and
callWithoutRetries.
it looks the timeout setup of callWithRetries is good, while callWithoutRetries
is wrong(multi RPC for this user): caller cannot specify a valid timeout, but
callWithoutRetries still calls beforeCall, which looks a method for
callWithRetries only, to set timeout. since RpcRetryingCaller#callTimeout is
not set, thread local timeout is set to 2s(MIN_RPC_TIMEOUT) via
RpcClient.setRpcTimeout, which is the final pinginterval set to the socket.
when there are heavy write workload and the rpc cannot complete in 2s, the
client close the connection, so the server side connection is reset and finally
exposes the problem in HBASE-11705
was:
Discussed on the user@hbase mailing list
(http://markmail.org/thread/w3cqjxwo2smkn2jw)
"Recently switched from 0.94 and 0.98, and finding that periodically things
are having issues - lots of retry exceptions" :
2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158,
table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops,
last exception: java.net.SocketTimeoutException: Call to
ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed
because java.net.SocketTimeoutException: 2000 millis timeout while waiting
for channel to be ready for read. ch :
java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014
remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on
ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking
started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500
ops.
there are 2 methods in RpcRetryingCaller: callWithRetries and
callWithoutRetries.
it looks the timeout setup of callWithRetries is good, while callWithoutRetries
is wrong(multi RPC for this user): caller cannot specify a valid timeout, but
callWithoutRetries still calls beforeCall, which looks a method for
callWithRetries only, to set timeout. since RpcRetryingCaller#callTimeout is
not set, thread local timeout is set to 2s(MIN_RPC_TIMEOUT) via
RpcClient.setRpcTimeout, which is the final pinginterval set to the socket.
when there are heavy write workload and the rpc cannot complete in 2s, the
client close the connection, so the server side connection is reset and finally
exposes the problem in HBASE-11705
> RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
> -
>
> Key: HBASE-11714
> URL: https://issues.apache.org/jira/browse/HBASE-11714
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Affects Versions: 0.98.3
>Reporter: Qiang Tian
>Assignee: Qiang Tian
> Attachments: hbase-11714-0.98.patch
>
>
> Discussed on the user@hbase mailing list
> (http://markmail.org/thread/w3cqjxwo2smkn2jw)
> {quote}
> "Recently switched from 0.94 and 0.98, and finding that periodically things
> are having issues - lots of retry exceptions" :
> {quote}
> client log:
> {quote}
> 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158,
> table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops,
> last exception: java.net.SocketTimeoutException: Call to
> ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed
> because java.net.SocketTimeoutException: 2000 millis timeout while waiting
> for channel to be ready for read. ch :
> java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014
> remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on
> ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking
> started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500
> ops.
> {quote}
> analysis:
> there
[jira] [Commented] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092416#comment-14092416 ] Qiang Tian commented on HBASE-11714: search hit: http://stackoverflow.com/questions/25038030/sockettimeoutexception-emerges-when-insert-millions-of-records-to-hbase I'd think below one is also the hit: https://issues.apache.org/jira/browse/PHOENIX-998 > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > Attachments: hbase-11714-0.98.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally exposes the problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11714) RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly
[ https://issues.apache.org/jira/browse/HBASE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092410#comment-14092410 ] Qiang Tian commented on HBASE-11714: ping [~apurtell], thanks! > RpcRetryingCaller#callWithoutRetries set rpc timeout to 2 seconds incorrectly > - > > Key: HBASE-11714 > URL: https://issues.apache.org/jira/browse/HBASE-11714 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 0.98.3 >Reporter: Qiang Tian >Assignee: Qiang Tian > Attachments: hbase-11714-0.98.patch > > > Discussed on the user@hbase mailing list > (http://markmail.org/thread/w3cqjxwo2smkn2jw) > "Recently switched from 0.94 and 0.98, and finding that periodically things > are having issues - lots of retry exceptions" : > 2014-08-08 17:22:43 o.a.h.h.c.AsyncProcess [INFO] #105158, > table=rt_global_monthly_campaign_deliveries, attempt=10/35 failed 500 ops, > last exception: java.net.SocketTimeoutException: Call to > ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020 failed > because java.net.SocketTimeoutException: 2000 millis timeout while waiting > for channel to be ready for read. ch : > java.nio.channels.SocketChannel[connected local=/10.248.130.152:46014 > remote=ip-10-201-128-23.us-west-1.compute.internal/10.201.128.23:60020] on > ip-10-201-128-23.us-west-1.compute.internal,60020,1405642103651, tracking > started Fri Aug 08 17:21:55 UTC 2014, retrying after 10043 ms, replay 500 > ops. > there are 2 methods in RpcRetryingCaller: callWithRetries and > callWithoutRetries. > it looks the timeout setup of callWithRetries is good, while > callWithoutRetries is wrong(multi RPC for this user): caller cannot specify a > valid timeout, but callWithoutRetries still calls beforeCall, which looks a > method for callWithRetries only, to set timeout. since > RpcRetryingCaller#callTimeout is not set, thread local timeout is set to > 2s(MIN_RPC_TIMEOUT) via RpcClient.setRpcTimeout, which is the final > pinginterval set to the socket. > when there are heavy write workload and the rpc cannot complete in 2s, the > client close the connection, so the server side connection is reset and > finally exposes the problem in HBASE-11705 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11699) Region servers exclusion list to HMaster.
[ https://issues.apache.org/jira/browse/HBASE-11699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gomathivinayagam Muthuvinayagam updated HBASE-11699: Attachment: HBASE-11699.patch > Region servers exclusion list to HMaster. > - > > Key: HBASE-11699 > URL: https://issues.apache.org/jira/browse/HBASE-11699 > Project: HBase > Issue Type: New Feature > Components: Admin, Client, regionserver, Zookeeper >Affects Versions: 0.98.3 >Reporter: Gomathivinayagam Muthuvinayagam >Priority: Minor > Fix For: 0.99.0, 2.0.0, 0.98.6 > > Attachments: HBASE-11699.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > Currently HBase does not support adding set of region servers to be in the > exclusion list. So that administrators can prevent accidental startups of > some region servers to join the cluster. There was initially some work done, > and it is available in https://issues.apache.org/jira/browse/HBASE-3833. It > was not done after that. > I am planning to contribute it as a patch, and I would like to do some > improvements as well. Instead of storing the exclusion entries on a file, I > am planning to store it on zookeeper. Can anyone suggest thoughts on this? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092398#comment-14092398
]
Hadoop QA commented on HBASE-11708:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660906/HBASE_11708-v2.patch
against trunk revision .
ATTACHMENT ID: 12660906
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10376//console
This message is automatically generated.
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708-v2.patch, HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11656) Document how to script snapshots
[
https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092391#comment-14092391
]
Hadoop QA commented on HBASE-11656:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660902/HBASE-11656.patch
against trunk revision .
ATTACHMENT ID: 12660902
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10375//console
This message is automatically generated.
> Document how to script snapshots
>
>
> Key: HBASE-11656
> URL: https://issues.apache.org/jira/browse/HBASE-11656
> Project: HBase
> Issue Type: Sub-task
> Components: documentation, shell
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Attachments: HBASE-11656.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11643) Read and write MOB in HBase
[
https://issues.apache.org/jira/browse/HBASE-11643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092377#comment-14092377
]
Hadoop QA commented on HBASE-11643:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660907/HBASE-11643-V5.diff
against trunk revision .
ATTACHMENT ID: 12660907
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 20 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.wal.TestLogRollingNoCluster
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10377//console
This message is automatically generated.
> Read and write MOB in HBase
> ---
>
> Key: HBASE-11643
> URL: https://issues.apache.org/jira/browse/HBASE-11643
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
>Reporter: Jingcheng Du
>Assignee: Jingcheng Du
> Attachments: HBASE-11643-V2.diff, HBASE-11643-V3.diff,
> HBASE-11643-V4.diff, HBASE-11643-V5.diff, HBase-11643.diff
>
>
> The read/write MOB in HBase are implemented in this JIRA. Normally, the Cells
> are saved in the MemStore, and flushed to the HFiles when necessary. For MOB,
> the Cells are saved in the MemStore as well, but they're flushed to elsewhere
> out of HBase in the format of HFiles.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11643) Read and write MOB in HBase
[ https://issues.apache.org/jira/browse/HBASE-11643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingcheng Du updated HBASE-11643: - Attachment: HBASE-11643-V4.diff > Read and write MOB in HBase > --- > > Key: HBASE-11643 > URL: https://issues.apache.org/jira/browse/HBASE-11643 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-11643-V2.diff, HBASE-11643-V3.diff, > HBASE-11643-V4.diff, HBASE-11643-V5.diff, HBase-11643.diff > > > The read/write MOB in HBase are implemented in this JIRA. Normally, the Cells > are saved in the MemStore, and flushed to the HFiles when necessary. For MOB, > the Cells are saved in the MemStore as well, but they're flushed to elsewhere > out of HBase in the format of HFiles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11643) Read and write MOB in HBase
[ https://issues.apache.org/jira/browse/HBASE-11643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingcheng Du updated HBASE-11643: - Attachment: (was: HBASE-11643-V4.patch) > Read and write MOB in HBase > --- > > Key: HBASE-11643 > URL: https://issues.apache.org/jira/browse/HBASE-11643 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-11643-V2.diff, HBASE-11643-V3.diff, > HBASE-11643-V4.diff, HBASE-11643-V5.diff, HBase-11643.diff > > > The read/write MOB in HBase are implemented in this JIRA. Normally, the Cells > are saved in the MemStore, and flushed to the HFiles when necessary. For MOB, > the Cells are saved in the MemStore as well, but they're flushed to elsewhere > out of HBase in the format of HFiles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11685) Incr/decr on the reference count of HConnectionImplementation need be atomic
[
https://issues.apache.org/jira/browse/HBASE-11685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092358#comment-14092358
]
Liu Shaohui commented on HBASE-11685:
-
[~apurtell]
{quote}
I really think we need to preserve the earlier logic
{quote}
I'm sorry that i didn't get your meanings? is the earlier logic just the
current codebase?
The current codebase, the connection may never be closed out for two threads
concurrently decrease the ref counter.
And the following code just hides the the possible bug that there are more
decCount ops than incCount ops in the code.
{code}
void decCount() {
if (refCount > 0) {
--refCount;
}
}
{code}
In my opinion,we should expose the bug as early as possible.
(1) When the count goes negative, we should print warn log or throw an
exception.
(2) When someone forgets to call the decCount, and the ref count always be
positive , the connection never be closed. we can find this problem from the
output of jstack.
I think the change doesn't introduce a new class of bug.
> Incr/decr on the reference count of HConnectionImplementation need be atomic
> -
>
> Key: HBASE-11685
> URL: https://issues.apache.org/jira/browse/HBASE-11685
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-11685-trunk-v1.diff, HBASE-11685-trunk-v2.diff,
> HBASE-11685-trunk-v3.diff, HBASE-11685-trunk-v4.diff
>
>
> Currently, the incr/decr operation on the ref count of
> HConnectionImplementation are not atomic. This may cause that the ref count
> always be larger than 0 and the connection never be closed.
> {code}
> /**
> * Increment this client's reference count.
> */
> void incCount() {
> ++refCount;
> }
> /**
> * Decrement this client's reference count.
> */
> void decCount() {
> if (refCount > 0) {
> --refCount;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11643) Read and write MOB in HBase
[ https://issues.apache.org/jira/browse/HBASE-11643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingcheng Du updated HBASE-11643: - Attachment: HBASE-11643-V5.diff Re-attach the patch. The tests are added. > Read and write MOB in HBase > --- > > Key: HBASE-11643 > URL: https://issues.apache.org/jira/browse/HBASE-11643 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Jingcheng Du >Assignee: Jingcheng Du > Attachments: HBASE-11643-V2.diff, HBASE-11643-V3.diff, > HBASE-11643-V4.patch, HBASE-11643-V5.diff, HBase-11643.diff > > > The read/write MOB in HBase are implemented in this JIRA. Normally, the Cells > are saved in the MemStore, and flushed to the HFiles when necessary. For MOB, > the Cells are saved in the MemStore as well, but they're flushed to elsewhere > out of HBase in the format of HFiles. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
louis hust updated HBASE-11708:
---
Attachment: HBASE_11708-v2.patch
Add the new patch which modify the identent
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708-v2.patch, HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
louis hust updated HBASE-11708:
---
Attachment: (was: HBASE_11708.patch)
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11656) Document how to script snapshots
[ https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11656: Status: Patch Available (was: Open) > Document how to script snapshots > > > Key: HBASE-11656 > URL: https://issues.apache.org/jira/browse/HBASE-11656 > Project: HBase > Issue Type: Sub-task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11656.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work stopped] (HBASE-11656) Document how to script snapshots
[ https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-11656 stopped by Misty Stanley-Jones. > Document how to script snapshots > > > Key: HBASE-11656 > URL: https://issues.apache.org/jira/browse/HBASE-11656 > Project: HBase > Issue Type: Sub-task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11656.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11656) Document how to script snapshots
[ https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11656: Attachment: HBASE-11656.patch Created a simple script do take a snapshot. > Document how to script snapshots > > > Key: HBASE-11656 > URL: https://issues.apache.org/jira/browse/HBASE-11656 > Project: HBase > Issue Type: Sub-task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11656.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (HBASE-11656) Document how to script snapshots
[ https://issues.apache.org/jira/browse/HBASE-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-11656 started by Misty Stanley-Jones. > Document how to script snapshots > > > Key: HBASE-11656 > URL: https://issues.apache.org/jira/browse/HBASE-11656 > Project: HBase > Issue Type: Sub-task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11656.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11476) Expand 'Conceptual View' section of Data Model chapter
[
https://issues.apache.org/jira/browse/HBASE-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092324#comment-14092324
]
Hadoop QA commented on HBASE-11476:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660888/HBASE-11476.patch
against trunk revision .
ATTACHMENT ID: 12660888
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ You can specify the maximum number of versions of a value
that HBase retains, per column
+ You can read a very understandable explanation of the HBase data
model in the blog post http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable";>Understanding
+
xlink:href="http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/9353-login1210_khurana.pdf";>Introduction
+com.example.www. The
contents:html column qualifier contains the entire
+text it used in the anchor of its link. The people
column family represents
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10373//console
This message is automatically generated.
> Expand 'Conceptual View' section of Data Model chapter
> ---
>
> Key: HBASE-11476
> URL: https://issues.apache.org/jira/browse/HBASE-11476
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Attachments: HBASE-11476.patch, HBASE-11476.patch
>
>
> Could use some updating and expansion to emphasize the differences between
> HBase and an RDBMS. I found
> http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
> which is just excellent and we should link to it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
[
https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092315#comment-14092315
]
Hadoop QA commented on HBASE-4593:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12660885/HBASE-4593.patch
against trunk revision .
ATTACHMENT ID: 12660885
{color:red}-1 @author{color}. The patch appears to contain 2 @author tags
which the Hadoop community has agreed to not allow in code contributions.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+
xlink:href="https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)"
+http://hbase.apache.org/mail-lists.html";>mailing lists page.
+There are varying levels of experience on both lists so
patience and politeness are encouraged (and please
+
xlink:href="https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20labels%20in%20(beginner)"
+mvn clean install
-DskipTests
+
xlink:href="http://michaelmorello.blogspot.com/2011/09/hbase-subversion-eclipse-windows.html";
+mvn -DskipTests clean install && mvn
-DskipTests package assembly:single
+
hbase-assembly/target/hbase--bin.tar.gz.
+
[jira] [Updated] (HBASE-11655) Document how to use Bash with HBase Shell
[ https://issues.apache.org/jira/browse/HBASE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11655: Attachment: HBASE-11655.patch Updated based on HBASE-11658 being committed. > Document how to use Bash with HBase Shell > - > > Key: HBASE-11655 > URL: https://issues.apache.org/jira/browse/HBASE-11655 > Project: HBase > Issue Type: Task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11655.patch, HBASE-11655.txt > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11655) Document how to use Bash with HBase Shell
[ https://issues.apache.org/jira/browse/HBASE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11655: Status: Patch Available (was: Open) > Document how to use Bash with HBase Shell > - > > Key: HBASE-11655 > URL: https://issues.apache.org/jira/browse/HBASE-11655 > Project: HBase > Issue Type: Task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11655.patch, HBASE-11655.txt > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11699) Region servers exclusion list to HMaster.
[ https://issues.apache.org/jira/browse/HBASE-11699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092289#comment-14092289 ] Gomathivinayagam Muthuvinayagam commented on HBASE-11699: - I will send out the code review shortly. Just a few pointers what I have done 1) There will be one config file, which will have entries for including and excluding region servers. = allow/deny 2) Added functions in HBaseAdmin to refresh the config file. Initially when the ServerManager class is initiated, the config file will be refreshed. So if there are any region servers which are online and also excluded will be expired. 3) Changed HMaster to support the functions, also regenerated protobuf classes. > Region servers exclusion list to HMaster. > - > > Key: HBASE-11699 > URL: https://issues.apache.org/jira/browse/HBASE-11699 > Project: HBase > Issue Type: New Feature > Components: Admin, Client, regionserver, Zookeeper >Affects Versions: 0.98.3 >Reporter: Gomathivinayagam Muthuvinayagam >Priority: Minor > Fix For: 0.99.0, 2.0.0, 0.98.6 > > Original Estimate: 96h > Remaining Estimate: 96h > > Currently HBase does not support adding set of region servers to be in the > exclusion list. So that administrators can prevent accidental startups of > some region servers to join the cluster. There was initially some work done, > and it is available in https://issues.apache.org/jira/browse/HBASE-3833. It > was not done after that. > I am planning to contribute it as a patch, and I would like to do some > improvements as well. Instead of storing the exclusion entries on a file, I > am planning to store it on zookeeper. Can anyone suggest thoughts on this? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11655) Document how to use Bash with HBase Shell
[ https://issues.apache.org/jira/browse/HBASE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11655: Status: Open (was: Patch Available) > Document how to use Bash with HBase Shell > - > > Key: HBASE-11655 > URL: https://issues.apache.org/jira/browse/HBASE-11655 > Project: HBase > Issue Type: Task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11655.txt > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (HBASE-11655) Document how to use Bash with HBase Shell
[ https://issues.apache.org/jira/browse/HBASE-11655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones reassigned HBASE-11655: --- Assignee: Misty Stanley-Jones > Document how to use Bash with HBase Shell > - > > Key: HBASE-11655 > URL: https://issues.apache.org/jira/browse/HBASE-11655 > Project: HBase > Issue Type: Task > Components: documentation, shell >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11655.txt > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11476) Expand 'Conceptual View' section of Data Model chapter
[ https://issues.apache.org/jira/browse/HBASE-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11476: Status: Patch Available (was: Open) > Expand 'Conceptual View' section of Data Model chapter > --- > > Key: HBASE-11476 > URL: https://issues.apache.org/jira/browse/HBASE-11476 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11476.patch, HBASE-11476.patch > > > Could use some updating and expansion to emphasize the differences between > HBase and an RDBMS. I found > http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable > which is just excellent and we should link to it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11476) Expand 'Conceptual View' section of Data Model chapter
[ https://issues.apache.org/jira/browse/HBASE-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11476: Attachment: HBASE-11476.patch Addressed feedback from [~j...@cloudera.com] > Expand 'Conceptual View' section of Data Model chapter > --- > > Key: HBASE-11476 > URL: https://issues.apache.org/jira/browse/HBASE-11476 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11476.patch, HBASE-11476.patch > > > Could use some updating and expansion to emphasize the differences between > HBase and an RDBMS. I found > http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable > which is just excellent and we should link to it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11476) Expand 'Conceptual View' section of Data Model chapter
[ https://issues.apache.org/jira/browse/HBASE-11476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11476: Status: Open (was: Patch Available) > Expand 'Conceptual View' section of Data Model chapter > --- > > Key: HBASE-11476 > URL: https://issues.apache.org/jira/browse/HBASE-11476 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-11476.patch, HBASE-11476.patch > > > Could use some updating and expansion to emphasize the differences between > HBase and an RDBMS. I found > http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable > which is just excellent and we should link to it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
[ https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-4593: --- Attachment: Chapter_18_and_19.pdf > Design and document the official procedure for posting patches, commits, > commit messages, etc. to smooth process and make integration with tools easier > --- > > Key: HBASE-4593 > URL: https://issues.apache.org/jira/browse/HBASE-4593 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Jonathan Gray >Assignee: Misty Stanley-Jones > Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, > HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch > > > I have been building a tool (currently called reposync) to help me keep the > internal FB hbase-92-based branch up-to-date with the public branches. > Various inconsistencies in our process has made it difficult to automate a > lot of this stuff. > I'd like to work with everyone to come up with the official best practices > and stick to it. > I welcome all suggestions. Among some of the things I'd like to nail down: > - Commit message format > - Best practice and commit message format for multiple commits > - Multiple commits per jira vs. jira per commit, what are the exceptions and > when > - Affects vs. Fix versions > - Potential usage of [tags] in commit messages for things like book, scripts, > shell... maybe even whatever is in the components field? > - Increased usage of JIRA tags or labels to mark exactly which repos a JIRA > has been committed to (potentially even internal repos? ways for a tool to > keep track in JIRA?) > We also need to be more strict about some things if we want to follow Apache > guidelines. For example, all final versions of a patch must be attached to > JIRA so that the author properly assigns it to Apache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
[ https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-4593: --- Attachment: HBASE-4593.patch Integrated latest round of feedback. Structure of chapter 18 changed a bit. > Design and document the official procedure for posting patches, commits, > commit messages, etc. to smooth process and make integration with tools easier > --- > > Key: HBASE-4593 > URL: https://issues.apache.org/jira/browse/HBASE-4593 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Jonathan Gray >Assignee: Misty Stanley-Jones > Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, > HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch > > > I have been building a tool (currently called reposync) to help me keep the > internal FB hbase-92-based branch up-to-date with the public branches. > Various inconsistencies in our process has made it difficult to automate a > lot of this stuff. > I'd like to work with everyone to come up with the official best practices > and stick to it. > I welcome all suggestions. Among some of the things I'd like to nail down: > - Commit message format > - Best practice and commit message format for multiple commits > - Multiple commits per jira vs. jira per commit, what are the exceptions and > when > - Affects vs. Fix versions > - Potential usage of [tags] in commit messages for things like book, scripts, > shell... maybe even whatever is in the components field? > - Increased usage of JIRA tags or labels to mark exactly which repos a JIRA > has been committed to (potentially even internal repos? ways for a tool to > keep track in JIRA?) > We also need to be more strict about some things if we want to follow Apache > guidelines. For example, all final versions of a patch must be attached to > JIRA so that the author properly assigns it to Apache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
[ https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-4593: --- Status: Patch Available (was: Open) > Design and document the official procedure for posting patches, commits, > commit messages, etc. to smooth process and make integration with tools easier > --- > > Key: HBASE-4593 > URL: https://issues.apache.org/jira/browse/HBASE-4593 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Jonathan Gray >Assignee: Misty Stanley-Jones > Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, > HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch > > > I have been building a tool (currently called reposync) to help me keep the > internal FB hbase-92-based branch up-to-date with the public branches. > Various inconsistencies in our process has made it difficult to automate a > lot of this stuff. > I'd like to work with everyone to come up with the official best practices > and stick to it. > I welcome all suggestions. Among some of the things I'd like to nail down: > - Commit message format > - Best practice and commit message format for multiple commits > - Multiple commits per jira vs. jira per commit, what are the exceptions and > when > - Affects vs. Fix versions > - Potential usage of [tags] in commit messages for things like book, scripts, > shell... maybe even whatever is in the components field? > - Increased usage of JIRA tags or labels to mark exactly which repos a JIRA > has been committed to (potentially even internal repos? ways for a tool to > keep track in JIRA?) > We also need to be more strict about some things if we want to follow Apache > guidelines. For example, all final versions of a patch must be attached to > JIRA so that the author properly assigns it to Apache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-4593) Design and document the official procedure for posting patches, commits, commit messages, etc. to smooth process and make integration with tools easier
[ https://issues.apache.org/jira/browse/HBASE-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-4593: --- Status: Open (was: Patch Available) > Design and document the official procedure for posting patches, commits, > commit messages, etc. to smooth process and make integration with tools easier > --- > > Key: HBASE-4593 > URL: https://issues.apache.org/jira/browse/HBASE-4593 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Jonathan Gray >Assignee: Misty Stanley-Jones > Attachments: Chapter_18_and_19.pdf, Chapter_18_and_19.pdf, > HBASE-4593.patch, HBASE-4593.patch, HBASE-4593.patch > > > I have been building a tool (currently called reposync) to help me keep the > internal FB hbase-92-based branch up-to-date with the public branches. > Various inconsistencies in our process has made it difficult to automate a > lot of this stuff. > I'd like to work with everyone to come up with the official best practices > and stick to it. > I welcome all suggestions. Among some of the things I'd like to nail down: > - Commit message format > - Best practice and commit message format for multiple commits > - Multiple commits per jira vs. jira per commit, what are the exceptions and > when > - Affects vs. Fix versions > - Potential usage of [tags] in commit messages for things like book, scripts, > shell... maybe even whatever is in the components field? > - Increased usage of JIRA tags or labels to mark exactly which repos a JIRA > has been committed to (potentially even internal repos? ways for a tool to > keep track in JIRA?) > We also need to be more strict about some things if we want to follow Apache > guidelines. For example, all final versions of a patch must be attached to > JIRA so that the author properly assigns it to Apache. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (HBASE-10247) Client promises about timestamps
[ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092247#comment-14092247 ] Lars Hofhansl edited comment on HBASE-10247 at 8/10/14 10:38 PM: - I think we should get least at the user facing changes in 1.0. [~enis]. Then throughout the 1.0 cycle (or for later versions) we can work in implementing the actual optimizations. A world without major compactions might be possible for table where clients no longer define timestamps (or where client always produce monotonically increasing timestamps). was (Author: lhofhansl): I think we should get at the user facing changes in 1.0. [~enis]. Then throughout the 1.0 cycle (or for later versions) we can work in implementing the actual optimizations. A world without major compactions might be possible for table where clients no longer define timestamps (or where client always produce monotonically increasing timestamps). > Client promises about timestamps > > > Key: HBASE-10247 > URL: https://issues.apache.org/jira/browse/HBASE-10247 > Project: HBase > Issue Type: Brainstorming >Reporter: Lars Hofhansl >Priority: Minor > > This is to start a discussion about timestamp promises declared per table of > CF. > For example if a client promises only monotonically increasing timestamps (or > no custom set timestamps) and VERSIONS=1, we can aggressively and easily > remove old versions of the same row/fam/col from the memstore before we > flush, just by supplying a comparator that ignores the timestamp (i.e. two KV > just differing by TS would be considered equal). > That would increase the performance of counters significantly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-10247) Client promises about timestamps
[ https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092247#comment-14092247 ] Lars Hofhansl commented on HBASE-10247: --- I think we should get at the user facing changes in 1.0. [~enis]. Then throughout the 1.0 cycle (or for later versions) we can work in implementing the actual optimizations. A world without major compactions might be possible for table where clients no longer define timestamps (or where client always produce monotonically increasing timestamps). > Client promises about timestamps > > > Key: HBASE-10247 > URL: https://issues.apache.org/jira/browse/HBASE-10247 > Project: HBase > Issue Type: Brainstorming >Reporter: Lars Hofhansl >Priority: Minor > > This is to start a discussion about timestamp promises declared per table of > CF. > For example if a client promises only monotonically increasing timestamps (or > no custom set timestamps) and VERSIONS=1, we can aggressively and easily > remove old versions of the same row/fam/col from the memstore before we > flush, just by supplying a comparator that ignores the timestamp (i.e. two KV > just differing by TS would be considered equal). > That would increase the performance of counters significantly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11715) HBase should provide a tool to compare 2 remote tables.
[ https://issues.apache.org/jira/browse/HBASE-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092200#comment-14092200 ] Alex Newman commented on HBASE-11715: - Could you provide some more details 1. How is this table copied. Do we flush and just move the HFiles over. 2. What do we do if they are not equivalent. Is it enough to throw an error, or do we need to say what part of the table isn't equivalent. 3. Do Merkle trees make sense for this type of thing? > HBase should provide a tool to compare 2 remote tables. > --- > > Key: HBASE-11715 > URL: https://issues.apache.org/jira/browse/HBASE-11715 > Project: HBase > Issue Type: New Feature >Reporter: Jean-Marc Spaggiari > > As discussed in the mailing list, when a table is copied to another cluster > and need to be validated against the first one, only VerifyReplication can be > used. However, this can be very long since data need to be copied again. > We should provide an easier and faster way to compare the tables. > One option is to calculate hashs per ranges. User can define number of > buckets, then we split the table into this number of buckets and calculate an > hash for each (Like partitioner is already doing). We can also optionally > calculate an overall CRC to reduce even more hash collision. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11715) HBase should provide a tool to compare 2 remote tables.
[ https://issues.apache.org/jira/browse/HBASE-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Newman updated HBASE-11715: Issue Type: New Feature (was: Bug) > HBase should provide a tool to compare 2 remote tables. > --- > > Key: HBASE-11715 > URL: https://issues.apache.org/jira/browse/HBASE-11715 > Project: HBase > Issue Type: New Feature >Reporter: Jean-Marc Spaggiari > > As discussed in the mailing list, when a table is copied to another cluster > and need to be validated against the first one, only VerifyReplication can be > used. However, this can be very long since data need to be copied again. > We should provide an easier and faster way to compare the tables. > One option is to calculate hashs per ranges. User can define number of > buckets, then we split the table into this number of buckets and calculate an > hash for each (Like partitioner is already doing). We can also optionally > calculate an overall CRC to reduce even more hash collision. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11715) HBase should provide a tool to compare 2 remote tables.
Jean-Marc Spaggiari created HBASE-11715: --- Summary: HBase should provide a tool to compare 2 remote tables. Key: HBASE-11715 URL: https://issues.apache.org/jira/browse/HBASE-11715 Project: HBase Issue Type: Bug Reporter: Jean-Marc Spaggiari As discussed in the mailing list, when a table is copied to another cluster and need to be validated against the first one, only VerifyReplication can be used. However, this can be very long since data need to be copied again. We should provide an easier and faster way to compare the tables. One option is to calculate hashs per ranges. User can define number of buckets, then we split the table into this number of buckets and calculate an hash for each (Like partitioner is already doing). We can also optionally calculate an overall CRC to reduce even more hash collision. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11708) RegionSplitter incorrectly calculates splitcount
[
https://issues.apache.org/jira/browse/HBASE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
louis hust updated HBASE-11708:
---
Attachment: HBASE_11708.patch
hi,[~busbey], I modify the indent not only the code i introduce, but also the
original code which with the wrong indent.
> RegionSplitter incorrectly calculates splitcount
>
>
> Key: HBASE-11708
> URL: https://issues.apache.org/jira/browse/HBASE-11708
> Project: HBase
> Issue Type: Bug
> Components: Admin, util
>Affects Versions: 0.96.2, 0.98.1
>Reporter: Sean Busbey
>Assignee: louis hust
>Priority: Minor
> Labels: beginner
> Attachments: HBASE_11708.patch, HBASE_11708.patch
>
>
> From discussion on HBASE-11627:
> {quote}
> And I also find another bug about the caculation of the variable splitCount
> which is cause by the wrong caculation of variable finished.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-9203) Secondary index support through coprocessors
[ https://issues.apache.org/jira/browse/HBASE-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14092057#comment-14092057 ] Nathan M commented on HBASE-9203: - I'm keen to see this. What is the progress. Anything I can do to help? > Secondary index support through coprocessors > > > Key: HBASE-9203 > URL: https://issues.apache.org/jira/browse/HBASE-9203 > Project: HBase > Issue Type: New Feature >Reporter: rajeshbabu >Assignee: rajeshbabu > Attachments: SecondaryIndex Design.pdf, SecondaryIndex > Design_Updated.pdf, SecondaryIndex Design_Updated_2.pdf > > > We have been working on implementing secondary index in HBase and open > sourced on hbase 0.94.8 version. > The project is available on github. > https://github.com/Huawei-Hadoop/hindex > This Jira is to support secondary index on trunk(0.98). > Following features will be supported. > - multiple indexes on table, > - multi column index, > - index based on part of a column value, > - equals and range condition scans using index, and > - bulk loading data to indexed table (Indexing done with bulk load) > Most of the kernel changes needed for secondary index is available in trunk. > Very minimal changes needed for it. -- This message was sent by Atlassian JIRA (v6.2#6252)
