[jira] [Updated] (HBASE-19252) Move the transform logic of FilterList into transformCell() method to avoid extra ref to question cell
[
https://issues.apache.org/jira/browse/HBASE-19252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-19252:
-
Fix Version/s: 1.4.1
Status: Patch Available (was: Open)
> Move the transform logic of FilterList into transformCell() method to avoid
> extra ref to question cell
> ---
>
> Key: HBASE-19252
> URL: https://issues.apache.org/jira/browse/HBASE-19252
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
> Fix For: 2.0.0, 1.4.1
>
> Attachments: HBASE-19252.v1.patch
>
>
> As [~anoop.hbase] and I discussed, we can implement the filterKeyValue ()
> and transformCell() methods as following to avoid saving transformedCell &
> referenceCell state in FilterList, and we can avoid the costly cell clone.
> {code}
> ReturnCode filterKeyValue(Cell c){
> ReturnCode rc = null;
> for(Filter filter: sub-filters){
> // ...
> rc = mergeReturnCode(rc, filter.filterKeyValue(c));
> // ...
> }
> return rc;
> }
> Cell transformCell(Cell c) throws IOException {
> Cell transformed = c;
> for(Filter filter: sub-filters){
> if(filter.filterKeyValue(c) is INCLUDE*) { // > line#1
> transformed = filter.transformCell(transformed);
>
> }
> }
> return transformed;
> }
> {code}
> For line #1, we need to remember the return code of the sub-filter for its
> filterKeyValue(). because only INCLUDE* ReturnCode, we need to
> transformCell for sub-filter.
> A new boolean array will be introduced in FilterList. and the cost of
> maintaining the boolean array will be less than the cost of maintaining the
> two ref of question cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19252) Move the transform logic of FilterList into transformCell() method to avoid extra ref to question cell
[
https://issues.apache.org/jira/browse/HBASE-19252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-19252:
-
Attachment: HBASE-19252.v1.patch
> Move the transform logic of FilterList into transformCell() method to avoid
> extra ref to question cell
> ---
>
> Key: HBASE-19252
> URL: https://issues.apache.org/jira/browse/HBASE-19252
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-19252.v1.patch
>
>
> As [~anoop.hbase] and I discussed, we can implement the filterKeyValue ()
> and transformCell() methods as following to avoid saving transformedCell &
> referenceCell state in FilterList, and we can avoid the costly cell clone.
> {code}
> ReturnCode filterKeyValue(Cell c){
> ReturnCode rc = null;
> for(Filter filter: sub-filters){
> // ...
> rc = mergeReturnCode(rc, filter.filterKeyValue(c));
> // ...
> }
> return rc;
> }
> Cell transformCell(Cell c) throws IOException {
> Cell transformed = c;
> for(Filter filter: sub-filters){
> if(filter.filterKeyValue(c) is INCLUDE*) { // > line#1
> transformed = filter.transformCell(transformed);
>
> }
> }
> return transformed;
> }
> {code}
> For line #1, we need to remember the return code of the sub-filter for its
> filterKeyValue(). because only INCLUDE* ReturnCode, we need to
> transformCell for sub-filter.
> A new boolean array will be introduced in FilterList. and the cost of
> maintaining the boolean array will be less than the cost of maintaining the
> two ref of question cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19252) Move the transform logic of FilterList into transformCell() method to avoid extra ref to question cell
[
https://issues.apache.org/jira/browse/HBASE-19252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-19252:
-
Fix Version/s: 2.0.0
> Move the transform logic of FilterList into transformCell() method to avoid
> extra ref to question cell
> ---
>
> Key: HBASE-19252
> URL: https://issues.apache.org/jira/browse/HBASE-19252
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-19252.v1.patch
>
>
> As [~anoop.hbase] and I discussed, we can implement the filterKeyValue ()
> and transformCell() methods as following to avoid saving transformedCell &
> referenceCell state in FilterList, and we can avoid the costly cell clone.
> {code}
> ReturnCode filterKeyValue(Cell c){
> ReturnCode rc = null;
> for(Filter filter: sub-filters){
> // ...
> rc = mergeReturnCode(rc, filter.filterKeyValue(c));
> // ...
> }
> return rc;
> }
> Cell transformCell(Cell c) throws IOException {
> Cell transformed = c;
> for(Filter filter: sub-filters){
> if(filter.filterKeyValue(c) is INCLUDE*) { // > line#1
> transformed = filter.transformCell(transformed);
>
> }
> }
> return transformed;
> }
> {code}
> For line #1, we need to remember the return code of the sub-filter for its
> filterKeyValue(). because only INCLUDE* ReturnCode, we need to
> transformCell for sub-filter.
> A new boolean array will be introduced in FilterList. and the cost of
> maintaining the boolean array will be less than the cost of maintaining the
> two ref of question cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251035#comment-16251035
]
Hudson commented on HBASE-19249:
SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #2028 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/2028/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
434097db0fe6e7f47097446a4061bf2133ae8b83)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19251) Merge RawAsyncTable and AsyncTable
[ https://issues.apache.org/jira/browse/HBASE-19251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-19251: -- Assignee: Duo Zhang Status: Patch Available (was: Open) > Merge RawAsyncTable and AsyncTable > -- > > Key: HBASE-19251 > URL: https://issues.apache.org/jira/browse/HBASE-19251 > Project: HBase > Issue Type: Improvement >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19251.patch > > > As discussed in HBASE-18978. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19251) Merge RawAsyncTable and AsyncTable
[
https://issues.apache.org/jira/browse/HBASE-19251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-19251:
--
Attachment: HBASE-19251.patch
Introduce a ScanResultConsumerBase. There are two sub classes which are
ScanResultConcumer which is for AsyncTableImpl, and AdvancedScanResultConsumer
which is for RawAsyncTableImpl.
Now the hierarchy is
{code}
public interface AsyncTable
class RawAsyncTableImpl implements AsyncTable
class AsyncTableImpl implements AsyncTable
{code}
What do you think? [~appy]. If you think this is OK then I will upload the
patch to rb for more reviewing.
Thanks.
> Merge RawAsyncTable and AsyncTable
> --
>
> Key: HBASE-19251
> URL: https://issues.apache.org/jira/browse/HBASE-19251
> Project: HBase
> Issue Type: Improvement
>Reporter: Duo Zhang
> Attachments: HBASE-19251.patch
>
>
> As discussed in HBASE-18978.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
[
https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251013#comment-16251013
]
Duo Zhang commented on HBASE-19216:
---
For a peer change, I think it is idempotent, so we can retry forever if an RS
fails to report in. We can have a nonce to prevent useless refresh but an extra
refresh will not effect correctness. So here I would say that there is no
rollback for this procedure.
And for ServerCrashProcedure, we can just skip the refresh on this node as it
will load the new peer config when restarting. Also for
ServerNotRunningYetException, maybe we have the same logic for unassign region?
{quote}
When you need this by?
{quote}
The synchronous replication needs this for state transition. The current
'eventually done' semantic for changing the peer config is not enough. So, the
earlier the better :)
Anyway, I can do it by myself, but I need to confirm that my approach is
correct.
Thanks.
> Use procedure to execute replication peer related operations
>
>
> Key: HBASE-19216
> URL: https://issues.apache.org/jira/browse/HBASE-19216
> Project: HBase
> Issue Type: Improvement
>Reporter: Duo Zhang
>
> When building the basic framework for HBASE-19064, I found that the
> enable/disable peer is built upon the watcher of zk.
> The problem of using watcher is that, you do not know the exact time when all
> RSes in the cluster have done the change, it is a 'eventually done'.
> And for synchronous replication, when changing the state of a replication
> peer, we need to know the exact time as we can only enable read/write after
> that time. So I think we'd better use procedure to do this. Change the flag
> on zk, and then execute a procedure on all RSes to reload the flag from zk.
> Another benefit is that, after the change, zk will be mainly used as a
> storage, so it will be easy to implement another replication peer storage to
> replace zk so that we can reduce the dependency on zk.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19009) implement modifyTable and enable/disableTableReplication for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19009: --- Attachment: HBASE-19009.master.011.patch > implement modifyTable and enable/disableTableReplication for AsyncAdmin > --- > > Key: HBASE-19009 > URL: https://issues.apache.org/jira/browse/HBASE-19009 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 3.0.0, 2.0.0-beta-1 > > Attachments: HBASE-19009.master.001.patch, > HBASE-19009.master.002.patch, HBASE-19009.master.003.patch, > HBASE-19009.master.004.patch, HBASE-19009.master.005.patch, > HBASE-19009.master.006.patch, HBASE-19009.master.007.patch, > HBASE-19009.master.008.patch, HBASE-19009.master.009.patch, > HBASE-19009.master.010.patch, HBASE-19009.master.011.patch > > > Add 3 methods to AsyncAdmin. > modifyTable() > enableTableReplication() > disableTableReplication() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.
[ https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251002#comment-16251002 ] Lars Hofhansl commented on HBASE-12091: --- Going to commit to branch-1, branch-2, and master. > Optionally ignore edits for dropped tables for replication. > --- > > Key: HBASE-12091 > URL: https://issues.apache.org/jira/browse/HBASE-12091 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0 > > Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, > 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, > 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, > 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091.txt > > > We just ran into a scenario where we dropped a table from both the source and > the sink, but the source still has outstanding edits that now it could not > get rid of. Now all replication is backed up behind these unreplicatable > edits. > We should have an option to ignore edits for tables dropped at the source. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251000#comment-16251000 ] stack commented on HBASE-19250: --- +1 on patch. Thanks for port to branch-2. > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12091) Optionally ignore edits for dropped tables for replication.
[
https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251001#comment-16251001
]
Lars Hofhansl commented on HBASE-12091:
---
I removed the unconditional sleeps from the tests: {{Thread.sleep(SLEEP_TIME *
NB_RETRIES);}}. They are not needed and this shaves about 30s off the run time.
Ran tests in a loop for 40 minutes (20 times). Passed each time.
> Optionally ignore edits for dropped tables for replication.
> ---
>
> Key: HBASE-12091
> URL: https://issues.apache.org/jira/browse/HBASE-12091
> Project: HBase
> Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0
>
> Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt,
> 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt,
> 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt,
> 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091.txt
>
>
> We just ran into a scenario where we dropped a table from both the source and
> the sink, but the source still has outstanding edits that now it could not
> get rid of. Now all replication is backed up behind these unreplicatable
> edits.
> We should have an option to ignore edits for tables dropped at the source.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19200) make hbase-client only depend on ZKAsyncRegistry and ZNodePaths
[ https://issues.apache.org/jira/browse/HBASE-19200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250998#comment-16250998 ] stack commented on HBASE-19200: --- [~appy] ok. Sounds good. i took a look at the zk break-out patch and i see that it is zk util, watchers, server-side util, minizkcluster, that are in hbase-zookeeper, stuff the hbase-client can do w/o. We need release note here though? Overview on the nice cleanup? > make hbase-client only depend on ZKAsyncRegistry and ZNodePaths > --- > > Key: HBASE-19200 > URL: https://issues.apache.org/jira/browse/HBASE-19200 > Project: HBase > Issue Type: Task > Components: Client, Zookeeper >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19200-v1.patch, HBASE-19200-v2.patch, > HBASE-19200-v3.patch, HBASE-19200-v4.patch, HBASE-19200-v5.patch, > HBASE-19200.patch > > > So that we can move most of the zookeeper related code out of hbase-client > module. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
[ https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250989#comment-16250989 ] stack commented on HBASE-19216: --- Sounds fine. The steps you describe resemble how open/close region work (AssignProcedure and UnassignProcedure) except you are doing a fan out to all RegionServers and then they are all to phone home to the Master when done? What if all RS fail to report in? Procedures need to complete. Could 'fail' and we do 'rollback/cleanup'? What if a RS dies? ServerCrashProcedure cleans up stuck Assign/Unassigns. Could do similar. Currently, open region (AssignProcedure) schedules remote request. The Procedure then suspends itself. The RS RPCs to Master to tell it Region open. The Master then 'wakes up' the suspended procedure to proceed (or fail). When you need this by? > Use procedure to execute replication peer related operations > > > Key: HBASE-19216 > URL: https://issues.apache.org/jira/browse/HBASE-19216 > Project: HBase > Issue Type: Improvement >Reporter: Duo Zhang > > When building the basic framework for HBASE-19064, I found that the > enable/disable peer is built upon the watcher of zk. > The problem of using watcher is that, you do not know the exact time when all > RSes in the cluster have done the change, it is a 'eventually done'. > And for synchronous replication, when changing the state of a replication > peer, we need to know the exact time as we can only enable read/write after > that time. So I think we'd better use procedure to do this. Change the flag > on zk, and then execute a procedure on all RSes to reload the flag from zk. > Another benefit is that, after the change, zk will be mainly used as a > storage, so it will be easy to implement another replication peer storage to > replace zk so that we can reduce the dependency on zk. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs
[
https://issues.apache.org/jira/browse/HBASE-19092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250980#comment-16250980
]
stack commented on HBASE-19092:
---
Is PrivateCellUtil used in Mutation? Is PCU what CU became?
TagUtil.clone => Tag.clone instead looks good.
Seeing this nice movement of util into Tag class makes me wonder how much we
could move into Cell.
Why is {@link PrivateCellUtil#MAX_TAGS_LENGTH} define, in PCU and not in Tag?
Is that all the methods we need to extract tags (Looking at ExtendedCell)?
Can you get rid of TagsUtil? Put in PCU?
Can TagType be a subclass of Tag?
I think this approach promising. I think it looks good. Can timeline server do
all it needs w/ the Tag vocabulary exposed here? Thanks.
> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch,
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch,
> HBASE-19092_001-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use
> tags like timeline server. The same topic was discussed in dev@ and also in
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to
> LimitedPrivate Util classes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers
[ https://issues.apache.org/jira/browse/HBASE-19253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-19253: - Attachment: HBASE-19253.master.001.patch > Dynamic change MemStoreFlusher FlushHandler workers > --- > > Key: HBASE-19253 > URL: https://issues.apache.org/jira/browse/HBASE-19253 > Project: HBase > Issue Type: Improvement >Reporter: binlijin >Assignee: binlijin > Attachments: HBASE-19253.master.001.patch > > > Use update_config to dynamic change MemStoreFlusher FlushHandler workers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
[ https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250952#comment-16250952 ] Duo Zhang commented on HBASE-19216: --- I would like to execute the procedure like this: 1. Execute a AddPeerProcedure. 2. Return several RefreshPeerConfigProcedures as sub procedure which are remote procedures. And the parent procedure is suspended. 3. For each RefreshPeerConfigProcedure, we will schedule a remote request, and it will be sent by calling executeProcedure. The procedure will also be suspended after scheduling the call. 4. We will have a way to wake up the RefreshPeerConfigProcedure and tell it that the refresh is done on RS(this is the problem here). 5. After all the sub procedure are done, we wake up the AddPeerProcedure. 6. AddPeerProcedure will do some post works(like logging) and finish. So the decision here is that, executeProcedure should be an asynchronous call, and the return value is useless. When the procedure is done at RS side, it will call a method to notify the master? Thanks. > Use procedure to execute replication peer related operations > > > Key: HBASE-19216 > URL: https://issues.apache.org/jira/browse/HBASE-19216 > Project: HBase > Issue Type: Improvement >Reporter: Duo Zhang > > When building the basic framework for HBASE-19064, I found that the > enable/disable peer is built upon the watcher of zk. > The problem of using watcher is that, you do not know the exact time when all > RSes in the cluster have done the change, it is a 'eventually done'. > And for synchronous replication, when changing the state of a replication > peer, we need to know the exact time as we can only enable read/write after > that time. So I think we'd better use procedure to do this. Change the flag > on zk, and then execute a procedure on all RSes to reload the flag from zk. > Another benefit is that, after the change, zk will be mainly used as a > storage, so it will be easy to implement another replication peer storage to > replace zk so that we can reduce the dependency on zk. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs
[
https://issues.apache.org/jira/browse/HBASE-19092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250942#comment-16250942
]
Hadoop QA commented on HBASE-19092:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-19092 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.6.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-19092 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897455/HBASE-19092-branch-2_5.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9789/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Make Tag IA.LimitedPrivate and expose for CPs
> -
>
> Key: HBASE-19092
> URL: https://issues.apache.org/jira/browse/HBASE-19092
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19092-branch-2.patch,
> HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch,
> HBASE-19092_001-branch-2.patch
>
>
> We need to make tags as LimitedPrivate as some use cases are trying to use
> tags like timeline server. The same topic was discussed in dev@ and also in
> HBASE-18995.
> Shall we target this for beta1 - cc [~saint@gmail.com].
> So once we do this all related Util methods and APIs should also move to
> LimitedPrivate Util classes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers
[ https://issues.apache.org/jira/browse/HBASE-19253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-19253: --- Issue Type: Improvement (was: Bug) > Dynamic change MemStoreFlusher FlushHandler workers > --- > > Key: HBASE-19253 > URL: https://issues.apache.org/jira/browse/HBASE-19253 > Project: HBase > Issue Type: Improvement >Reporter: binlijin >Assignee: binlijin > > Use update_config to dynamic change MemStoreFlusher FlushHandler workers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[
https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250935#comment-16250935
]
Hadoop QA commented on HBASE-19250:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 8m
13s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
54s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
29s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
64m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}148m 9s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}242m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19250 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897427/HBASE-19250.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux dfcc273f9079 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 80741e31e8 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/9785/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9785/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9785/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> TestClientClusterStatus is flaky
>
>
>
[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs
[ https://issues.apache.org/jira/browse/HBASE-19092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-19092: --- Status: Patch Available (was: Open) > Make Tag IA.LimitedPrivate and expose for CPs > - > > Key: HBASE-19092 > URL: https://issues.apache.org/jira/browse/HBASE-19092 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19092-branch-2.patch, > HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, > HBASE-19092_001-branch-2.patch > > > We need to make tags as LimitedPrivate as some use cases are trying to use > tags like timeline server. The same topic was discussed in dev@ and also in > HBASE-18995. > Shall we target this for beta1 - cc [~saint@gmail.com]. > So once we do this all related Util methods and APIs should also move to > LimitedPrivate Util classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19092) Make Tag IA.LimitedPrivate and expose for CPs
[ https://issues.apache.org/jira/browse/HBASE-19092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-19092: --- Attachment: HBASE-19092-branch-2_5.patch Try QA. > Make Tag IA.LimitedPrivate and expose for CPs > - > > Key: HBASE-19092 > URL: https://issues.apache.org/jira/browse/HBASE-19092 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19092-branch-2.patch, > HBASE-19092-branch-2_5.patch, HBASE-19092-branch-2_5.patch, > HBASE-19092_001-branch-2.patch > > > We need to make tags as LimitedPrivate as some use cases are trying to use > tags like timeline server. The same topic was discussed in dev@ and also in > HBASE-18995. > Shall we target this for beta1 - cc [~saint@gmail.com]. > So once we do this all related Util methods and APIs should also move to > LimitedPrivate Util classes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19248) TestZooKeeper#testMultipleZK fails due to missing method getKeepAliveZooKeeperWatcher
[
https://issues.apache.org/jira/browse/HBASE-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250927#comment-16250927
]
Hadoop QA commented on HBASE-19248:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
56s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
44s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
39s{color} | {color:red} hbase-client: The patch generated 1 new + 0 unchanged
- 1 fixed = 1 total (was 1) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
25s{color} | {color:red} hbase-server: The patch generated 8 new + 28 unchanged
- 2 fixed = 36 total (was 30) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
59s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
71m 56s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
14s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
34s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}153m
45s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}260m 28s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19248 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897420/HBASE-19248.0.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux bf1c9ea56fd6 3.13.0-133-generic #182-Ubuntu SMP Tue Sep 19
15:49:21 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
|
[jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
[ https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250923#comment-16250923 ] stack commented on HBASE-19216: --- Pv2 could be good for this. RS would report to the Master when+seqid they'd completed a peer operation (like a RegionServer reporting it had opened a Region)? Would that work? Outline what the steps you think involved and then let me give you pointers. Our doc is incomplete [1] and it is not straight-forward (unfortunately) how stuff works. Let me try and save you some head-banging. [~Apache9] 1. https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.xp9zndoycwj > Use procedure to execute replication peer related operations > > > Key: HBASE-19216 > URL: https://issues.apache.org/jira/browse/HBASE-19216 > Project: HBase > Issue Type: Improvement >Reporter: Duo Zhang > > When building the basic framework for HBASE-19064, I found that the > enable/disable peer is built upon the watcher of zk. > The problem of using watcher is that, you do not know the exact time when all > RSes in the cluster have done the change, it is a 'eventually done'. > And for synchronous replication, when changing the state of a replication > peer, we need to know the exact time as we can only enable read/write after > that time. So I think we'd better use procedure to do this. Change the flag > on zk, and then execute a procedure on all RSes to reload the flag from zk. > Another benefit is that, after the change, zk will be mainly used as a > storage, so it will be easy to implement another replication peer storage to > replace zk so that we can reduce the dependency on zk. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250912#comment-16250912
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-2.0 #850 (See
[https://builds.apache.org/job/HBase-2.0/850/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev d0fb4bd78386181868576610e27f921a13849efd)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/BlockingRpcConnection.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250911#comment-16250911 ] Hudson commented on HBASE-19250: FAILURE: Integrated in Jenkins build HBase-2.0 #850 (See [https://builds.apache.org/job/HBase-2.0/850/]) HBASE-19250 TestClientClusterStatus is flaky (apurtell: rev efe116f11a747421906d44964a1f78761192a2c3) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19237) TestMaster.testMasterOpsWhileSplitting fails
[
https://issues.apache.org/jira/browse/HBASE-19237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250910#comment-16250910
]
Hudson commented on HBASE-19237:
FAILURE: Integrated in Jenkins build HBase-2.0 #850 (See
[https://builds.apache.org/job/HBase-2.0/850/])
HBASE-19237: TestMaster.testMasterOpsWhileSplitting fails (tedyu: rev
57aa6b32a240db0715dd9195f34319a6440fd2d0)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMaster.java
> TestMaster.testMasterOpsWhileSplitting fails
>
>
> Key: HBASE-19237
> URL: https://issues.apache.org/jira/browse/HBASE-19237
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Yi Liang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19237-master-v1.patch, HBASE-19237-master-v1.patch
>
>
> This is the top flaky test:
> {code}
> java.lang.AssertionError: expected:<3> but was:<1>
> at
> org.apache.hadoop.hbase.master.TestMaster.testMasterOpsWhileSplitting(TestMaster.java:121)
> {code}
> After brief check, the test failure seems to be introduced by HBASE-19127
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250913#comment-16250913
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-2.0 #850 (See
[https://builds.apache.org/job/HBase-2.0/850/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
d5df4c04268bef36e5c0f6f4fc37602c6f77c032)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250905#comment-16250905
]
Hadoop QA commented on HBASE-19210:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.6.0/precommit-patchnames for
instructions. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
84m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
19s{color} | {color:green} hbase-rest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}112m 15s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-19210 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897439/19210.addendum |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux d5389638a4d9 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 9ed6cf5cb8 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9787/testReport/ |
| modules | C: hbase-rest U: hbase-rest |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9787/console |
| Powered by | Apache Yetus
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250903#comment-16250903
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.2-IT #1016 (See
[https://builds.apache.org/job/HBase-1.2-IT/1016/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
79cc3b3145378c994c59c80ca27a1bd9f48f5d75)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250900#comment-16250900
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.3-IT #284 (See
[https://builds.apache.org/job/HBase-1.3-IT/284/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
dea935dab72afeb4b366bb5307ee69f04a4bc50e)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250899#comment-16250899
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.5 #155 (See
[https://builds.apache.org/job/HBase-1.5/155/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
bac254bd4249bbe2d8ccc377409719c9e59c78ae)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs
[ https://issues.apache.org/jira/browse/HBASE-19235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250897#comment-16250897 ] stack commented on HBASE-19235: --- I should say that in my chat w/ [~appy] , he said we should write up what we decide about IA inheritance so we clear what to do next time we run into it. I like how [~chia7712] calls it: "It makes sense to me that sub-class can always narrow the declaration (ex. IA.Public -> IA.Private/IA.LP)..." Added HBASE-19254 to write up our understanding here. > CoprocessorEnvironment should be exposed to CPs > --- > > Key: HBASE-19235 > URL: https://issues.apache.org/jira/browse/HBASE-19235 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0-alpha-4 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19235.patch, HBASE-19235_V2.patch > > > Its sub interfaces are exposed with > LimitedPrivate(HBaseInterfaceAudience.COPROC). So ideally all the functions > in this are. Better we mark CoprocessorEnvironment also as CP exposed to > avoid confusion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19254) Write up how InterfaceAudience works over class hierarchy
stack created HBASE-19254: - Summary: Write up how InterfaceAudience works over class hierarchy Key: HBASE-19254 URL: https://issues.apache.org/jira/browse/HBASE-19254 Project: HBase Issue Type: Task Components: documentation Reporter: stack Over on the tail of HBASE-19235, there is a discussion around marking classes with InterfaceAudicence in a hierarchy. One camp suggests that it could be possible that a super class might be IA.Private but subclasses (and their methods) could then be IA.LP. General opinion held the opposite. [~chia7712] said it best: bq. It makes sense to me that sub-class can always narrow the declaration (ex. IA.Public -> IA.Private/IA.LP). Widening the declaration is like a issue we need to fix. This issue is about adding a note to the IA section in refguide (should probably pass it by dev list before it goes into refguide). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250895#comment-16250895
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #276 (See
[https://builds.apache.org/job/HBase-1.2-JDK7/276/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
79cc3b3145378c994c59c80ca27a1bd9f48f5d75)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250896#comment-16250896
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.2-JDK8 #273 (See
[https://builds.apache.org/job/HBase-1.2-JDK8/273/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
79cc3b3145378c994c59c80ca27a1bd9f48f5d75)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-19249:
Resolution: Fixed
Fix Version/s: 1.1.13
2.0.0-beta-1
1.2.7
1.5.0
1.3.2
1.4.0
3.0.0
Status: Resolved (was: Patch Available)
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250893#comment-16250893
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #345 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/345/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
dea935dab72afeb4b366bb5307ee69f04a4bc50e)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250892#comment-16250892
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #364 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/364/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
dea935dab72afeb4b366bb5307ee69f04a4bc50e)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250890#comment-16250890
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4050 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4050/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 9ed6cf5cb8f841f306170ac4fe50f172911ff483)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/BlockingRpcConnection.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250889#comment-16250889 ] Hudson commented on HBASE-19250: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4050 (See [https://builds.apache.org/job/HBase-Trunk_matrix/4050/]) HBASE-19250 TestClientClusterStatus is flaky (apurtell: rev b2c2729c42e245d85303782ea8b6a40023ce3d5d) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250891#comment-16250891
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4050 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4050/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
7406c83ef6f5c2f4620e8cbb48630d983c8ad57e)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250886#comment-16250886
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.1-JDK7 #1943 (See
[https://builds.apache.org/job/HBase-1.1-JDK7/1943/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
434097db0fe6e7f47097446a4061bf2133ae8b83)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19249) test for "hbase antipatterns" should check _count_ of occurance rather than text of
[
https://issues.apache.org/jira/browse/HBASE-19249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250887#comment-16250887
]
Hudson commented on HBASE-19249:
FAILURE: Integrated in Jenkins build HBase-1.4 #1014 (See
[https://builds.apache.org/job/HBase-1.4/1014/])
HBASE-19249 test for "hbase antipatterns" should check _count_ of (busbey: rev
ade166d5f80be1a6f57a36b9fc4a8ecee6e40d4d)
* (edit) dev-support/hbase-personality.sh
> test for "hbase antipatterns" should check _count_ of occurance rather than
> text of
> ---
>
> Key: HBASE-19249
> URL: https://issues.apache.org/jira/browse/HBASE-19249
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19249.0.patch
>
>
> [~appy] noticed on HBASE-18624 that our check for Hadoop annotations failed
> to flag a use.
> looking at our check:
> {code}
> warnings=$(${GREP} 'import org.apache.hadoop.classification' "${patchfile}")
> if [[ ${warnings} -gt 0 ]]; then
> add_vote_table -1 hbaseanti "" "The patch appears use Hadoop
> classification instead of HBase: ${warnings}."
> ((result=result+1))
> fi
> {code}
> That should have been a "grep -c" and not a "grep". So we've been falsely
> giving a negative on all these checks.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19240) Fix error-prone errors, part four?
[ https://issues.apache.org/jira/browse/HBASE-19240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250856#comment-16250856 ] Hudson commented on HBASE-19240: FAILURE: Integrated in Jenkins build HBase-1.4 #1013 (See [https://builds.apache.org/job/HBase-1.4/1013/]) HBASE-19240 more error-prone results (apurtell: rev 626d74f79a3d663850ab9c75f5bb0621bb82483d) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverForAddingMutationsFromCoprocessors.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeepDeletes.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreFileRefresherChore.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestRegionPlacement.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestEndToEndSplitTransaction.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemStoreChunkPool.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/MultiThreadedUpdaterWithACL.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestVersionModel.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/normalizer/TestSimpleRegionNormalizer.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationEndpoint.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/ipc/IntegrationTestRpcClient.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestServerNonceManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java > Fix error-prone errors, part four? > -- > > Key: HBASE-19240 > URL: https://issues.apache.org/jira/browse/HBASE-19240 > Project: HBase > Issue Type: Bug >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 1.5.0, 2.0.0-beta-1 > > Attachments: HBASE-19240.branch-1.patch, > HBASE-19240.branch-1.v2.patch, HBASE-19240.patch, HBASE-19240.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250851#comment-16250851
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-1.4 #1012 (See
[https://builds.apache.org/job/HBase-1.4/1012/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 4a3183dc91017911ef2f1d52e29a7a42cec62c37)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/BlockingRpcConnection.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250850#comment-16250850 ] Hudson commented on HBASE-19250: FAILURE: Integrated in Jenkins build HBase-1.4 #1012 (See [https://builds.apache.org/job/HBase-1.4/1012/]) HBASE-19250 TestClientClusterStatus is flaky (apurtell: rev d2a8436eb0bad9b19138c613090157094a1f6af3) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19240) Fix error-prone errors, part four?
[ https://issues.apache.org/jira/browse/HBASE-19240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250834#comment-16250834 ] Hudson commented on HBASE-19240: FAILURE: Integrated in Jenkins build HBase-1.5 #154 (See [https://builds.apache.org/job/HBase-1.5/154/]) HBASE-19240 more error-prone results (apurtell: rev dbcda15ae71ddcec1e380ed88d1307e12d2da055) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/MultiThreadedUpdaterWithACL.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestServerNonceManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestMemStoreChunkPool.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestKeepDeletes.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestRegionPlacement.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/normalizer/TestSimpleRegionNormalizer.java * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/model/TestVersionModel.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverForAddingMutationsFromCoprocessors.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationEndpoint.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreFileRefresherChore.java * (edit) hbase-it/src/test/java/org/apache/hadoop/hbase/ipc/IntegrationTestRpcClient.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestEndToEndSplitTransaction.java > Fix error-prone errors, part four? > -- > > Key: HBASE-19240 > URL: https://issues.apache.org/jira/browse/HBASE-19240 > Project: HBase > Issue Type: Bug >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 1.5.0, 2.0.0-beta-1 > > Attachments: HBASE-19240.branch-1.patch, > HBASE-19240.branch-1.v2.patch, HBASE-19240.patch, HBASE-19240.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250820#comment-16250820
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-1.5 #153 (See
[https://builds.apache.org/job/HBase-1.5/153/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 96b86b71d2f32f842e9ed57341ee3d7f4e8329f6)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/BlockingRpcConnection.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250819#comment-16250819 ] Hudson commented on HBASE-19250: FAILURE: Integrated in Jenkins build HBase-1.5 #153 (See [https://builds.apache.org/job/HBase-1.5/153/]) HBASE-19250 TestClientClusterStatus is flaky (apurtell: rev 45116c8a52d7114d87924478ae4381c4f88e90fd) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientClusterStatus.java > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs
[ https://issues.apache.org/jira/browse/HBASE-19235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250785#comment-16250785 ] Anoop Sam John commented on HBASE-19235: Appy. IMHO #2 is not at all good. Am not sure any other place we have like super interface is private and sub type as LP or public. I did not check. If so, we have to fix. I raised this issue after seeing a patch in Phoenix. The sub interfaces are LP exposed. So any functions available to it, can be called by user. Else the CP user has to really check in which interface it is declared and see its declaration. It will be very difficult task and confusing for sure. Ya we were having CPEnv interface as private till now. But we can cleanup now. Better late than never. I understood Chia comment to avoid the instance of check. Let me see. I thought we can make it simple. Like in old way. Let me see. > CoprocessorEnvironment should be exposed to CPs > --- > > Key: HBASE-19235 > URL: https://issues.apache.org/jira/browse/HBASE-19235 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0-alpha-4 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19235.patch, HBASE-19235_V2.patch > > > Its sub interfaces are exposed with > LimitedPrivate(HBaseInterfaceAudience.COPROC). So ideally all the functions > in this are. Better we mark CoprocessorEnvironment also as CP exposed to > avoid confusion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19210:
---
Attachment: 19210.addendum
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.addendum, 19210.v1.txt, 19210.v1.txt,
> 19210.v2.txt, 19210.v3.txt, HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19210:
---
Status: Patch Available (was: Reopened)
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.addendum, 19210.v1.txt, 19210.v1.txt,
> 19210.v2.txt, 19210.v3.txt, HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers
[ https://issues.apache.org/jira/browse/HBASE-19253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-19253: - Description: Use update_config to dynamic change MemStoreFlusher FlushHandler workers (was: Use update_config to dynamic change MemStoreFlusher FlushHandler numbers) > Dynamic change MemStoreFlusher FlushHandler workers > --- > > Key: HBASE-19253 > URL: https://issues.apache.org/jira/browse/HBASE-19253 > Project: HBase > Issue Type: Bug >Reporter: binlijin >Assignee: binlijin > > Use update_config to dynamic change MemStoreFlusher FlushHandler workers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler workers
[ https://issues.apache.org/jira/browse/HBASE-19253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin updated HBASE-19253: - Summary: Dynamic change MemStoreFlusher FlushHandler workers (was: Dynamic change MemStoreFlusher FlushHandler numbers) > Dynamic change MemStoreFlusher FlushHandler workers > --- > > Key: HBASE-19253 > URL: https://issues.apache.org/jira/browse/HBASE-19253 > Project: HBase > Issue Type: Bug >Reporter: binlijin >Assignee: binlijin > > Use update_config to dynamic change MemStoreFlusher FlushHandler numbers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19009) implement modifyTable and enable/disableTableReplication for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250771#comment-16250771 ] Guanghao Zhang commented on HBASE-19009: Great tool. But why this can't be shown on HADOOP QA result? > implement modifyTable and enable/disableTableReplication for AsyncAdmin > --- > > Key: HBASE-19009 > URL: https://issues.apache.org/jira/browse/HBASE-19009 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 3.0.0, 2.0.0-beta-1 > > Attachments: HBASE-19009.master.001.patch, > HBASE-19009.master.002.patch, HBASE-19009.master.003.patch, > HBASE-19009.master.004.patch, HBASE-19009.master.005.patch, > HBASE-19009.master.006.patch, HBASE-19009.master.007.patch, > HBASE-19009.master.008.patch, HBASE-19009.master.009.patch, > HBASE-19009.master.010.patch > > > Add 3 methods to AsyncAdmin. > modifyTable() > enableTableReplication() > disableTableReplication() -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler numbers
[ https://issues.apache.org/jira/browse/HBASE-19253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] binlijin reassigned HBASE-19253: Assignee: binlijin > Dynamic change MemStoreFlusher FlushHandler numbers > --- > > Key: HBASE-19253 > URL: https://issues.apache.org/jira/browse/HBASE-19253 > Project: HBase > Issue Type: Bug >Reporter: binlijin >Assignee: binlijin > > Use update_config to dynamic change MemStoreFlusher FlushHandler numbers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19253) Dynamic change MemStoreFlusher FlushHandler numbers
binlijin created HBASE-19253: Summary: Dynamic change MemStoreFlusher FlushHandler numbers Key: HBASE-19253 URL: https://issues.apache.org/jira/browse/HBASE-19253 Project: HBase Issue Type: Bug Reporter: binlijin Use update_config to dynamic change MemStoreFlusher FlushHandler numbers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19239) Fix findbugs and error-prone warnings
[ https://issues.apache.org/jira/browse/HBASE-19239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19239: --- Attachment: 0001-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch 0002-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch 0003-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch 0004-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch 0005-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch Parking what I have so far. Dependencies of hbase-server. hbase-server is next. Patches are for branch-1. > Fix findbugs and error-prone warnings > - > > Key: HBASE-19239 > URL: https://issues.apache.org/jira/browse/HBASE-19239 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 3.0.0, 1.4.0, 2.0.0-beta-1 > > Attachments: > 0001-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch, > 0002-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch, > 0003-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch, > 0004-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch, > 0005-HBASE-19239-Fix-findbugs-and-error-prone-issues.patch, > error-prone-branch-1.4.txt > > > Fix important findbugs and error-prone warnings on branch-1.4 / branch-1. > Forward port as appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18963) Remove MultiRowMutationProcessor and implement mutateRows... methods using batchMutate()
[
https://issues.apache.org/jira/browse/HBASE-18963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250751#comment-16250751
]
Hadoop QA commented on HBASE-18963:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
16s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
0s{color} | {color:green} hbase-server: The patch generated 0 new + 345
unchanged - 8 fixed = 345 total (was 353) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
41s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
65m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 2.7.4 or 3.0.0-alpha4. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
24s{color} | {color:red} hbase-server generated 2 new + 2 unchanged - 0 fixed =
4 total (was 2) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}106m
58s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}190m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18963 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897404/hbase-18963.master.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6e40e056e0d8 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 80741e31e8 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| javadoc |
https://builds.apache.org/job/PreCommit-HBASE-Build/9781/artifact/patchprocess/diff-javadoc-javadoc-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9781/testReport/ |
| modules | C: hbase-server U:
[jira] [Commented] (HBASE-19243) Start mini cluster once before class for TestFIFOCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250748#comment-16250748 ] Chia-Ping Tsai commented on HBASE-19243: 67.567 s -> 28.046 s +1 > Start mini cluster once before class for TestFIFOCompactionPolicy > - > > Key: HBASE-19243 > URL: https://issues.apache.org/jira/browse/HBASE-19243 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19243.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250739#comment-16250739
]
Ted Yu commented on HBASE-19210:
I run this code by itself which passed (note the legitimate call at the end):
{code}
@Test
public void testInvalidNamespacePuts() throws IOException, JAXBException {
Admin admin = TEST_UTIL.getAdmin();
Response response;
// Check that namespaces don't exist via non-REST call.
assertNull(findNamespace(admin, NAMESPACE1));
assertNull(findNamespace(admin, NAMESPACE2));
// Test cannot PUT (alter) non-existent namespace.
byte[] json = Bytes.toBytes(jsonMapper.writeValueAsString(model2));
response = client.put(namespacePath2, Constants.MIMETYPE_JSON, json);
assertEquals(403, response.getCode());
// Try REST post and puts with invalid content.
response = client.post(namespacePath1, Constants.MIMETYPE_JSON,
toXML(model1));
assertEquals(500, response.getCode());
response = client.put(namespacePath2, Constants.MIMETYPE_XML, json);
assertEquals(400, response.getCode());
// Create namespace via XML and JSON.
response = client.post(namespacePath1, Constants.MIMETYPE_XML,
toXML(model1));
assertEquals(201, response.getCode());
}
{code}
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18974) Document "Becoming a Committer"
[
https://issues.apache.org/jira/browse/HBASE-18974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250726#comment-16250726
]
Hadoop QA commented on HBASE-18974:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
46s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
48s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}235m
13s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}255m 22s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-18974 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12897393/HBASE-18974.v3.patch |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux 328f0ec1c608 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / df82abb159 |
| maven | version: Apache Maven 3.5.2
(138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z) |
| Default Java | 1.8.0_151 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9777/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9777/console |
| Powered by | Apache Yetus 0.6.0 http://yetus.apache.org |
This message was automatically generated.
> Document "Becoming a Committer"
> ---
>
> Key: HBASE-18974
> URL: https://issues.apache.org/jira/browse/HBASE-18974
> Project: HBase
> Issue Type: Bug
> Components: community, documentation
>Reporter: Mike Drob
>Assignee: Mike Drob
> Attachments: HBASE-18974.patch, HBASE-18974.v2.patch,
> HBASE-18974.v3.patch
>
>
> Based on the mailing list discussion at
> https://lists.apache.org/thread.html/81c633cbe1f6f78421cbdad5b9549643c67803a723a9d86a513264c0@%3Cdev.hbase.apache.org%3E
> it sounds like we should record some of the thoughts for future contributors
> to refer to.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250712#comment-16250712
]
Mike Drob commented on HBASE-19210:
---
testInvalidNamespacePuts will fail when run by itself.
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19239) Fix findbugs and error-prone warnings
[ https://issues.apache.org/jira/browse/HBASE-19239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19239: --- Summary: Fix findbugs and error-prone warnings (was: Fix important findbugs and error-prone warnings) > Fix findbugs and error-prone warnings > - > > Key: HBASE-19239 > URL: https://issues.apache.org/jira/browse/HBASE-19239 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 3.0.0, 1.4.0, 2.0.0-beta-1 > > Attachments: error-prone-branch-1.4.txt > > > Fix important findbugs and error-prone warnings on branch-1.4 / branch-1. > Forward port as appropriate. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19252) Move the transform logic of FilterList into transformCell() method to avoid extra ref to question cell
[
https://issues.apache.org/jira/browse/HBASE-19252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-19252:
-
Priority: Minor (was: Major)
Issue Type: Improvement (was: Bug)
> Move the transform logic of FilterList into transformCell() method to avoid
> extra ref to question cell
> ---
>
> Key: HBASE-19252
> URL: https://issues.apache.org/jira/browse/HBASE-19252
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
>
> As [~anoop.hbase] and I discussed, we can implement the filterKeyValue ()
> and transformCell() methods as following to avoid saving transformedCell &
> referenceCell state in FilterList, and we can avoid the costly cell clone.
> {code}
> ReturnCode filterKeyValue(Cell c){
> ReturnCode rc = null;
> for(Filter filter: sub-filters){
> // ...
> rc = mergeReturnCode(rc, filter.filterKeyValue(c));
> // ...
> }
> return rc;
> }
> Cell transformCell(Cell c) throws IOException {
> Cell transformed = c;
> for(Filter filter: sub-filters){
> if(filter.filterKeyValue(c) is INCLUDE*) { // > line#1
> transformed = filter.transformCell(transformed);
>
> }
> }
> return transformed;
> }
> {code}
> For line #1, we need to remember the return code of the sub-filter for its
> filterKeyValue(). because only INCLUDE* ReturnCode, we need to
> transformCell for sub-filter.
> A new boolean array will be introduced in FilterList. and the cost of
> maintaining the boolean array will be less than the cost of maintaining the
> two ref of question cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19240) Fix error-prone errors, part four?
[ https://issues.apache.org/jira/browse/HBASE-19240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19240: --- Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch-1.4 and branch-1 > Fix error-prone errors, part four? > -- > > Key: HBASE-19240 > URL: https://issues.apache.org/jira/browse/HBASE-19240 > Project: HBase > Issue Type: Bug >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 1.5.0, 2.0.0-beta-1 > > Attachments: HBASE-19240.branch-1.patch, > HBASE-19240.branch-1.v2.patch, HBASE-19240.patch, HBASE-19240.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19252) Move the transform logic of FilterList into transformCell() method to avoid extra ref to question cell
Zheng Hu created HBASE-19252:
Summary: Move the transform logic of FilterList into
transformCell() method to avoid extra ref to question cell
Key: HBASE-19252
URL: https://issues.apache.org/jira/browse/HBASE-19252
Project: HBase
Issue Type: Bug
Reporter: Zheng Hu
Assignee: Zheng Hu
As [~anoop.hbase] and I discussed, we can implement the filterKeyValue () and
transformCell() methods as following to avoid saving transformedCell &
referenceCell state in FilterList, and we can avoid the costly cell clone.
{code}
ReturnCode filterKeyValue(Cell c){
ReturnCode rc = null;
for(Filter filter: sub-filters){
// ...
rc = mergeReturnCode(rc, filter.filterKeyValue(c));
// ...
}
return rc;
}
Cell transformCell(Cell c) throws IOException {
Cell transformed = c;
for(Filter filter: sub-filters){
if(filter.filterKeyValue(c) is INCLUDE*) { // > line#1
transformed = filter.transformCell(transformed);
}
}
return transformed;
}
{code}
For line #1, we need to remember the return code of the sub-filter for its
filterKeyValue(). because only INCLUDE* ReturnCode, we need to
transformCell for sub-filter.
A new boolean array will be introduced in FilterList. and the cost of
maintaining the boolean array will be less than the cost of maintaining the
two ref of question cell.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250700#comment-16250700
]
Ted Yu commented on HBASE-19210:
testInvalidNamespacePosts and testInvalidNamespacePuts are ignored.
Which subtest shows the server failure ?
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250694#comment-16250694
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-1.3-IT #283 (See
[https://builds.apache.org/job/HBase-1.3-IT/283/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 26ff42091cc5f00df7e66db1e41b05868d551c59)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/IPCUtil.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19251) Merge RawAsyncTable and AsyncTable
Duo Zhang created HBASE-19251: - Summary: Merge RawAsyncTable and AsyncTable Key: HBASE-19251 URL: https://issues.apache.org/jira/browse/HBASE-19251 Project: HBase Issue Type: Improvement Reporter: Duo Zhang As discussed in HBASE-18978. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable
[ https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250693#comment-16250693 ] Duo Zhang commented on HBASE-18978: --- Or generic? Maybe. I could have a try. > Align the methods in Table and AsyncTable > - > > Key: HBASE-18978 > URL: https://issues.apache.org/jira/browse/HBASE-18978 > Project: HBase > Issue Type: Task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.0.0-beta-1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250691#comment-16250691
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #363 (See
[https://builds.apache.org/job/HBase-1.3-JDK8/363/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 26ff42091cc5f00df7e66db1e41b05868d551c59)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/IPCUtil.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250692#comment-16250692
]
Hudson commented on HBASE-19215:
FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #344 (See
[https://builds.apache.org/job/HBase-1.3-JDK7/344/])
HBASE-19215 Incorrect exception handling on the client causes incorrect
(apurtell: rev 26ff42091cc5f00df7e66db1e41b05868d551c59)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/IPCUtil.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClientImpl.java
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable
[
https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250690#comment-16250690
]
Duo Zhang commented on HBASE-18978:
---
The observer style API in RawAsyncTable is
{code}
void scan(Scan scan, RawScanResultConsumer consumer);
{code}
And in AsyncTable is
{code}
void scan(Scan scan, ScanResultConsumer consumer);
{code}
It is not easy to merge them, that's the key point. So we can declare both in
the merged interface, but for raw implementation, the latter one will throw
UNOE, and for the non-raw implementation, the former one will throw UNOE? Seems
ugly...
> Align the methods in Table and AsyncTable
> -
>
> Key: HBASE-18978
> URL: https://issues.apache.org/jira/browse/HBASE-18978
> Project: HBase
> Issue Type: Task
> Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 2.0.0-beta-1
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19240) Fix error-prone errors, part four?
[ https://issues.apache.org/jira/browse/HBASE-19240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250687#comment-16250687 ] Andrew Purtell commented on HBASE-19240: Looking at this now > Fix error-prone errors, part four? > -- > > Key: HBASE-19240 > URL: https://issues.apache.org/jira/browse/HBASE-19240 > Project: HBase > Issue Type: Bug >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 1.5.0, 2.0.0-beta-1 > > Attachments: HBASE-19240.branch-1.patch, > HBASE-19240.branch-1.v2.patch, HBASE-19240.patch, HBASE-19240.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (HBASE-12091) Optionally ignore edits for dropped tables for replication.
[ https://issues.apache.org/jira/browse/HBASE-12091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12091: --- Comment: was deleted (was: Let me see about committing this today. ) > Optionally ignore edits for dropped tables for replication. > --- > > Key: HBASE-12091 > URL: https://issues.apache.org/jira/browse/HBASE-12091 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 2.0.0, 3.0.0, 1.4.1, 1.5.0 > > Attachments: 12091-branch-2.patch, 12091-v2-branch-1.txt, > 12091-v3-branch-1.txt, 12091-v4-branch-1.txt, 12091-v5-branch-1.txt, > 12091-v6-branch-1.txt, 12091-v7-branch-1.txt, 12091-v7-master.txt, > 12091-v8-branch-1.txt, 12091-v8-master.txt, 12091.txt > > > We just ran into a scenario where we dropped a table from both the source and > the sink, but the source still has outstanding edits that now it could not > get rid of. Now all replication is backed up behind these unreplicatable > edits. > We should have an option to ignore edits for tables dropped at the source. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-19215:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to 1.3 and up
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19250: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0, 2.0.0-beta-1 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19216) Use procedure to execute replication peer related operations
[ https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250683#comment-16250683 ] Duo Zhang commented on HBASE-19216: --- Ping [~stack]. Need to know the state of procedure v2 and if there is already a plan to improve it? If no I will try to fix it by myself. Thanks. > Use procedure to execute replication peer related operations > > > Key: HBASE-19216 > URL: https://issues.apache.org/jira/browse/HBASE-19216 > Project: HBase > Issue Type: Improvement >Reporter: Duo Zhang > > When building the basic framework for HBASE-19064, I found that the > enable/disable peer is built upon the watcher of zk. > The problem of using watcher is that, you do not know the exact time when all > RSes in the cluster have done the change, it is a 'eventually done'. > And for synchronous replication, when changing the state of a replication > peer, we need to know the exact time as we can only enable read/write after > that time. So I think we'd better use procedure to do this. Change the flag > on zk, and then execute a procedure on all RSes to reload the flag from zk. > Another benefit is that, after the change, zk will be mainly used as a > storage, so it will be easy to implement another replication peer storage to > replace zk so that we can reduce the dependency on zk. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250685#comment-16250685
]
Mike Drob commented on HBASE-19210:
---
[~tedyu] - please look at the WIP patch that I had put up. It will show you the
exact sequence of REST calls that will make the server fall over.
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250684#comment-16250684
]
Ted Yu commented on HBASE-19210:
Modified the test slightly by inserting a legal call:
{code}
diff --git
a/hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInstanceResource.java
b/hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInsta
index 9c724cd..3af50df 100644
---
a/hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInstanceResource.java
+++
b/hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestNamespacesInstanceResource.java
@@ -270,13 +270,17 @@ public class TestNamespacesInstanceResource {
String jsonString = jsonMapper.writeValueAsString(model2);
response = client.put(namespacePath2, Constants.MIMETYPE_XML,
Bytes.toBytes(jsonString));
assertEquals(400, response.getCode());
+// Create namespace via XML and JSON.
+response = client.post(namespacePath1, Constants.MIMETYPE_XML,
toXML(model1));
+assertEquals(201, response.getCode());
+
response = client.post(namespacePath3, Constants.MIMETYPE_PROTOBUF,
toXML(model3));
assertEquals(500, response.getCode());
NamespaceDescriptor nd1 = findNamespace(admin, NAMESPACE1);
NamespaceDescriptor nd2 = findNamespace(admin, NAMESPACE2);
NamespaceDescriptor nd3 = findNamespace(admin, NAMESPACE3);
-assertNull(nd1);
+assertNotNull(nd1);
assertNull(nd2);
assertNull(nd3);
}
{code}
TestNamespacesInstanceResource#testInvalidNamespacePostsAndPuts, run
standalone, passed.
Meaning REST server responds to legal request.
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-19215:
---
Attachment: (was: HBASE-19215-branch-1.3.patch)
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-19215:
---
Attachment: HBASE-19215-branch-1.3.patch
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19243) Start mini cluster once before class for TestFIFOCompactionPolicy
[ https://issues.apache.org/jira/browse/HBASE-19243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250677#comment-16250677 ] Duo Zhang commented on HBASE-19243: --- Any concerns? [~stack] [~chia7712]. Thanks. > Start mini cluster once before class for TestFIFOCompactionPolicy > - > > Key: HBASE-19243 > URL: https://issues.apache.org/jira/browse/HBASE-19243 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-19243.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable
[ https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250674#comment-16250674 ] Duo Zhang commented on HBASE-18978: --- I'm fine with renaming. But I still do not think you can move the scan API from RawAsyncTable to AsyncTable. You can have a try to see if you can call the methods in RawScanResultConsumer in a thread pool and still make it usable. So merge the interface, but for the non-raw implementation, throw UnsupportedOperationException? > Align the methods in Table and AsyncTable > - > > Key: HBASE-18978 > URL: https://issues.apache.org/jira/browse/HBASE-18978 > Project: HBase > Issue Type: Task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.0.0-beta-1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19215) Incorrect exception handling on the client causes incorrect call timeouts and byte buffer allocations on the server
[
https://issues.apache.org/jira/browse/HBASE-19215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-19215:
---
Attachment: HBASE-19215-branch-1.3.patch
As [~abhishek.chouhan] mentioned, his patch applies to 1.4 and up. Here's a
patch for 1.3 that I'll commit shortly along with the rest.
> Incorrect exception handling on the client causes incorrect call timeouts and
> byte buffer allocations on the server
> ---
>
> Key: HBASE-19215
> URL: https://issues.apache.org/jira/browse/HBASE-19215
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Abhishek Singh Chouhan
>Assignee: Abhishek Singh Chouhan
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2
>
> Attachments: HBASE-19215-branch-1.3.patch,
> HBASE-19215.branch-1.001.patch
>
>
> Ran into the situation of oome on the client : java.lang.OutOfMemoryError:
> Direct buffer memory.
> When we encounter an unhandled exception during channel write at RpcClientImpl
> {noformat}
> checkIsOpen(); // Now we're checking that it didn't became idle in between.
> try {
> call.callStats.setRequestSizeBytes(IPCUtil.write(this.out, header,
> call.param,
> cellBlock));
> } catch (IOException e) {
> {noformat}
> we end up leaving the connection open. This becomes especially problematic
> when we get an unhandled exception between writing the length of our request
> on the channel and subsequently writing the params and cellblocks
> {noformat}
>*dos.write(Bytes.toBytes(totalSize));*
> // This allocates a buffer that is the size of the message internally.
> header.writeDelimitedTo(dos);
> if (param != null) param.writeDelimitedTo(dos);
> if (cellBlock != null) dos.write(cellBlock.array(), 0,
> cellBlock.remaining());
> dos.flush();
> return totalSize;
> {noformat}
> After reading the length rs allocates a bb and expects data to be filled.
> However when we encounter an exception during param write we release the
> writelock in rpcclientimpl and do not close the connection, the exception is
> handled at AbstractRpcClient.callBlockingMethod and retried. Now the next
> client request to the same rs writes to the channel however the server
> interprets this as part of the previous request and errors out during proto
> conversion when processing the request since its considered malformed(in the
> worst case this might be misinterpreted as wrong data?). Now the remaining
> data of the current request is read(the current request's size > prev
> request's allocated partially filled bytebuffer) and is misinterpreted as the
> size of new request, in my case this was in gbs. All the client requests time
> out since this bytebuffer is never completely filled. We should close the
> connection for any Throwable and not just ioexception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250670#comment-16250670
]
Hudson commented on HBASE-19210:
FAILURE: Integrated in Jenkins build HBase-2.0 #849 (See
[https://builds.apache.org/job/HBase-2.0/849/])
HBASE-19210 TestNamespacesInstanceResource fails (Ted Yu) (tedyu: rev
04a87fe1569641ff4a971b7b97ec239e7d065a86)
* (edit) pom.xml
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-19250: --- Attachment: HBASE-19250.patch > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0 > > Attachments: HBASE-19250-branch-1.patch, HBASE-19250.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19248) TestZooKeeper#testMultipleZK fails due to missing method getKeepAliveZooKeeperWatcher
[
https://issues.apache.org/jira/browse/HBASE-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250665#comment-16250665
]
Duo Zhang commented on HBASE-19248:
---
+1.
> TestZooKeeper#testMultipleZK fails due to missing method
> getKeepAliveZooKeeperWatcher
> -
>
> Key: HBASE-19248
> URL: https://issues.apache.org/jira/browse/HBASE-19248
> Project: HBase
> Issue Type: Test
> Components: Zookeeper
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19248.0.patch
>
>
> From
> https://builds.apache.org/job/HBASE-Flaky-Tests/23335/testReport/junit/org.apache.hadoop.hbase/TestZooKeeper/testMultipleZK/
> :
> {code}
> java.lang.NoSuchMethodException:
> org.apache.hadoop.hbase.client.ConnectionImplementation.getKeepAliveZooKeeperWatcher()
> at
> org.apache.hadoop.hbase.TestZooKeeper.getZooKeeperWatcher(TestZooKeeper.java:136)
> at
> org.apache.hadoop.hbase.TestZooKeeper.testMultipleZK(TestZooKeeper.java:291)
> {code}
> This is the top flaky test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19237) TestMaster.testMasterOpsWhileSplitting fails
[
https://issues.apache.org/jira/browse/HBASE-19237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19237:
---
Resolution: Fixed
Assignee: Yi Liang
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-beta-1
Status: Resolved (was: Patch Available)
Thanks Yi for the patch.
> TestMaster.testMasterOpsWhileSplitting fails
>
>
> Key: HBASE-19237
> URL: https://issues.apache.org/jira/browse/HBASE-19237
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Yi Liang
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19237-master-v1.patch, HBASE-19237-master-v1.patch
>
>
> This is the top flaky test:
> {code}
> java.lang.AssertionError: expected:<3> but was:<1>
> at
> org.apache.hadoop.hbase.master.TestMaster.testMasterOpsWhileSplitting(TestMaster.java:121)
> {code}
> After brief check, the test failure seems to be introduced by HBASE-19127
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250659#comment-16250659 ] Andrew Purtell commented on HBASE-19250: Wouldn't hurt. I will do that. Thanks for the review. > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0 > > Attachments: HBASE-19250-branch-1.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19248) TestZooKeeper#testMultipleZK fails due to missing method getKeepAliveZooKeeperWatcher
[
https://issues.apache.org/jira/browse/HBASE-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250657#comment-16250657
]
Duo Zhang commented on HBASE-19248:
---
Let me take a look.
> TestZooKeeper#testMultipleZK fails due to missing method
> getKeepAliveZooKeeperWatcher
> -
>
> Key: HBASE-19248
> URL: https://issues.apache.org/jira/browse/HBASE-19248
> Project: HBase
> Issue Type: Test
> Components: Zookeeper
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19248.0.patch
>
>
> From
> https://builds.apache.org/job/HBASE-Flaky-Tests/23335/testReport/junit/org.apache.hadoop.hbase/TestZooKeeper/testMultipleZK/
> :
> {code}
> java.lang.NoSuchMethodException:
> org.apache.hadoop.hbase.client.ConnectionImplementation.getKeepAliveZooKeeperWatcher()
> at
> org.apache.hadoop.hbase.TestZooKeeper.getZooKeeperWatcher(TestZooKeeper.java:136)
> at
> org.apache.hadoop.hbase.TestZooKeeper.testMultipleZK(TestZooKeeper.java:291)
> {code}
> This is the top flaky test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19237) TestMaster.testMasterOpsWhileSplitting fails
[
https://issues.apache.org/jira/browse/HBASE-19237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250655#comment-16250655
]
Hudson commented on HBASE-19237:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4049 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4049/])
HBASE-19237: TestMaster.testMasterOpsWhileSplitting fails (tedyu: rev
80741e31e8259dba6fc4181726394c6dbd56f026)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestMaster.java
> TestMaster.testMasterOpsWhileSplitting fails
>
>
> Key: HBASE-19237
> URL: https://issues.apache.org/jira/browse/HBASE-19237
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
> Attachments: HBASE-19237-master-v1.patch, HBASE-19237-master-v1.patch
>
>
> This is the top flaky test:
> {code}
> java.lang.AssertionError: expected:<3> but was:<1>
> at
> org.apache.hadoop.hbase.master.TestMaster.testMasterOpsWhileSplitting(TestMaster.java:121)
> {code}
> After brief check, the test failure seems to be introduced by HBASE-19127
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250653#comment-16250653
]
Hudson commented on HBASE-19210:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #4049 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/4049/])
HBASE-19210 Revert "Revert "TestNamespacesInstanceResource fails"" (mdrob: rev
14f87a1204ac8dd218806800f31e22a1b16e0538)
* (edit) pom.xml
HBASE-19210 TestNamespacesInstanceResource fails - revert due to missing
(tedyu: rev 42506a6bcb98cf7190ebf521ebafb6b31dc1076a)
* (edit) pom.xml
HBASE-19210 TestNamespacesInstanceResource fails (Ted Yu) (tedyu: rev
df82abb159e220e94d6c245e17e0c0c0fcc3a687)
* (edit) pom.xml
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19210) TestNamespacesInstanceResource fails
[
https://issues.apache.org/jira/browse/HBASE-19210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250654#comment-16250654
]
Sean Busbey commented on HBASE-19210:
-
If a set of calls can cause our REST service to fall over and fail to give
future responses, I'd say that's a problem with our REST service and not with
the test.
> TestNamespacesInstanceResource fails
>
>
> Key: HBASE-19210
> URL: https://issues.apache.org/jira/browse/HBASE-19210
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0-beta-1
>
> Attachments: 19210.v1.txt, 19210.v1.txt, 19210.v2.txt, 19210.v3.txt,
> HBASE-19210.WIP.patch
>
>
> This is the top flaky test.
> The following can be reproduced:
> {code}
> java.net.SocketException: Connection reset
> at
> org.apache.hadoop.hbase.rest.TestNamespacesInstanceResource.testInvalidNamespacePostsAndPuts(TestNamespacesInstanceResource.java:271)
> {code}
> With commit e320df5a0c267258c03909da8d0eee4c0e287532, the test passes.
> With commit 5facaded902a13556952b1f9d26b768cb86e6599, the test fails.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19248) TestZooKeeper#testMultipleZK fails due to missing method getKeepAliveZooKeeperWatcher
[
https://issues.apache.org/jira/browse/HBASE-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-19248:
Attachment: HBASE-19248.0.patch
-0
- move "test multiple zk" to TestZKAsyncRegistry, redone in terms of Curator
bits
- remove {{TestZooKeeper.testClientSessionExpired}}, which also needed the
internal ZKW but has been disabled for 5 years.
> TestZooKeeper#testMultipleZK fails due to missing method
> getKeepAliveZooKeeperWatcher
> -
>
> Key: HBASE-19248
> URL: https://issues.apache.org/jira/browse/HBASE-19248
> Project: HBase
> Issue Type: Test
> Components: Zookeeper
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19248.0.patch
>
>
> From
> https://builds.apache.org/job/HBASE-Flaky-Tests/23335/testReport/junit/org.apache.hadoop.hbase/TestZooKeeper/testMultipleZK/
> :
> {code}
> java.lang.NoSuchMethodException:
> org.apache.hadoop.hbase.client.ConnectionImplementation.getKeepAliveZooKeeperWatcher()
> at
> org.apache.hadoop.hbase.TestZooKeeper.getZooKeeperWatcher(TestZooKeeper.java:136)
> at
> org.apache.hadoop.hbase.TestZooKeeper.testMultipleZK(TestZooKeeper.java:291)
> {code}
> This is the top flaky test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19248) TestZooKeeper#testMultipleZK fails due to missing method getKeepAliveZooKeeperWatcher
[
https://issues.apache.org/jira/browse/HBASE-19248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-19248:
Status: Patch Available (was: In Progress)
> TestZooKeeper#testMultipleZK fails due to missing method
> getKeepAliveZooKeeperWatcher
> -
>
> Key: HBASE-19248
> URL: https://issues.apache.org/jira/browse/HBASE-19248
> Project: HBase
> Issue Type: Test
> Components: Zookeeper
>Affects Versions: 3.0.0, 2.0.0-beta-1
>Reporter: Ted Yu
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-19248.0.patch
>
>
> From
> https://builds.apache.org/job/HBASE-Flaky-Tests/23335/testReport/junit/org.apache.hadoop.hbase/TestZooKeeper/testMultipleZK/
> :
> {code}
> java.lang.NoSuchMethodException:
> org.apache.hadoop.hbase.client.ConnectionImplementation.getKeepAliveZooKeeperWatcher()
> at
> org.apache.hadoop.hbase.TestZooKeeper.getZooKeeperWatcher(TestZooKeeper.java:136)
> at
> org.apache.hadoop.hbase.TestZooKeeper.testMultipleZK(TestZooKeeper.java:291)
> {code}
> This is the top flaky test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19250) TestClientClusterStatus is flaky
[ https://issues.apache.org/jira/browse/HBASE-19250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250640#comment-16250640 ] Chia-Ping Tsai commented on HBASE-19250: LGTM. Should we push the patch to master also? > TestClientClusterStatus is flaky > > > Key: HBASE-19250 > URL: https://issues.apache.org/jira/browse/HBASE-19250 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Trivial > Fix For: 1.4.0 > > Attachments: HBASE-19250-branch-1.patch > > > testLiveAndDeadServersStatus(org.apache.hadoop.hbase.client.TestClientClusterStatus) > Time elapsed: 0.032 s <<< FAILURE! > java.lang.AssertionError > at > org.apache.hadoop.hbase.client.TestClientClusterStatus.testLiveAndDeadServersStatus(TestClientClusterStatus.java:110) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18978) Align the methods in Table and AsyncTable
[ https://issues.apache.org/jira/browse/HBASE-18978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250637#comment-16250637 ] Appy commented on HBASE-18978: -- bq. 'RawXXX' will execute the callbacks directly in the rpc framework thread, so it is a little dangerous for non-expert users as if you execute time-consuming tasks in the callback, the hbase client may be stuck. For the non-raw implementation, usually it is just a simple wrapper of the raw implementation. The difference is that, you need to provide a thread pool to execute the callbacks, so it will not block the rpc framework thread, which is safer for users. Okay, so if that's what 'raw' means, it totally makes sense. Like you have for admin - One interface and two implementations, one with separate threadpool and another with same thread pool (raw). AsyncAdmin <--- AsyncHBaseAdmin AsyncAdmin <--- RawAsyncHBaseAdmin That's clean and nice. bq. And for AsyncTable and RawAsyncTable, the scan API is a bit different. For RawAsyncTable there is a very low level observer style API. All other scan methods of async client are based on this API. It is not easy to write correct code with this API and I believe for most cases users do not need to use this method. This conflicts with above understanding of 'raw'. Going by previous meaning, there shouldn't be any 'raw' interfaces since that an implementation thing. Seems like 'raw' is being used for many things and that where the confusion arises. Can we either 1) Rename RawAsyncTable to something else, say, AdvancedAsyncTable, ExtendedAsyncTable or something else. Additionally, such advanced interface should extend basic interface for ease of use so that users using advanced one don't have to keep track of two interfaces/variables. OR 2) Merge it into AsyncTable: My personal preference, mainly because we shouldn't separate interfaces because 2 functions are "difficult to use" or less used. As long as we comment them properly, no dev will have trouble using/avoiding them, as appropriate. Thanks for the explanations Duo. What do you say about last point? > Align the methods in Table and AsyncTable > - > > Key: HBASE-18978 > URL: https://issues.apache.org/jira/browse/HBASE-18978 > Project: HBase > Issue Type: Task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Peter Somogyi >Priority: Critical > Fix For: 2.0.0-beta-1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19235) CoprocessorEnvironment should be exposed to CPs
[ https://issues.apache.org/jira/browse/HBASE-19235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16250632#comment-16250632 ] Chia-Ping Tsai commented on HBASE-19235: bq. I misunderstood the suggestion above. BaseEnvironment is internal... yeah, could be good to refer directly to it internally. I try to avoid the instanceof checks. bq. if we should allow it so super class can have different IA from subclass. Suggested we take that up elsewhere, especially if we can turn up another example where a super IA.Private when children are IA.LP or public would be convenient. It makes sense to me that sub-class can always narrow the declaration (ex. IA.Public -> IA.Private/IA.LP). Widening the declaration is like a issue we need to fix. > CoprocessorEnvironment should be exposed to CPs > --- > > Key: HBASE-19235 > URL: https://issues.apache.org/jira/browse/HBASE-19235 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Affects Versions: 2.0.0-alpha-4 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Minor > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19235.patch, HBASE-19235_V2.patch > > > Its sub interfaces are exposed with > LimitedPrivate(HBaseInterfaceAudience.COPROC). So ideally all the functions > in this are. Better we mark CoprocessorEnvironment also as CP exposed to > avoid confusion. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
