Successful: HBase Generate Website

2015-12-06 Thread Apache Jenkins Server 
Build status: Successful

If successful, the website and docs have been generated. If failed, skip to the 
bottom of this email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site:

  wget -O- 
https://builds.apache.org/job/hbase_generate_website/55/artifact/website.patch.zip
 | funzip > 8bf70144e40650ef972f005e2465bd0e2a087c40.patch
  git fetch
  git checkout -b asf-site-8bf70144e40650ef972f005e2465bd0e2a087c40 
origin/asf-site
  git am 8bf70144e40650ef972f005e2465bd0e2a087c40.patch

At this point, you can preview the changes by opening index.html or any of the 
other HTML pages in your local 
asf-site-8bf70144e40650ef972f005e2465bd0e2a087c40 branch, and you can review 
the differences by running:

  git diff origin/asf-site

When you are satisfied, publish your changes to origin/asf-site using this 
command:

  git push origin asf-site-8bf70144e40650ef972f005e2465bd0e2a087c40:asf-site

Changes take a couple of minutes to be propagated. You can then remove your 
asf-site-8bf70144e40650ef972f005e2465bd0e2a087c40 branch:

  git checkout master && git branch -d 
asf-site-8bf70144e40650ef972f005e2465bd0e2a087c40



If failed, see https://builds.apache.org/job/hbase_generate_website/55/console

Re: [VOTE] First release candidate for HBase 1.1.3 (RC0) is available

2015-12-06 Thread Andrew Purtell 
> Reopened HBASE-14605, HBASE-14655, and HBASE-14631 as blockers for 1.1.x
and 1.0.x. 

I don't think we could leave the underlying problems with incorrect user 
context for security alone on branches 1.0 and 1.1 unfixed. We can revert this 
stuff - these changes are at the end of a cascade of changes stemming from bug 
fixing - but then for sake of correct functioning of security features we'd 
want to move people to 1.2.



> On Dec 6, 2015, at 4:11 PM, Nick Dimiduk  wrote:
> 
> I found some source-incompatible changes in the compatibility report [0].
> Reopened HBASE-14605, HBASE-14655, and HBASE-14631 as blockers for 1.1.x
> and 1.0.x. Since I'm asking, would be good to see the last mile
> on HBASE-14822 and HBASE-14844.
> 
> [0]:
> http://home.apache.org/~ndimiduk/1.1.0_branch-1.1_compat_report.html#Type_Source_Problems_High
> 
>> On Wed, Dec 2, 2015 at 1:17 PM, Nick Dimiduk  wrote:
>> 
>> With HBASE-14689 resolved, I plan to spin the next RC this weekend. Let me
>> know if you have any concerns.
>> 
>> -n
>> 
>> On Tue, Nov 17, 2015 at 8:33 PM, Andrew Purtell 
>> wrote:
>> 
>>> Let's revert this from 0.98 even if the problem isn't manifesting there
>>> (or perhaps just not in the same way)
>>> 
>>> 
 On Nov 17, 2015, at 7:33 PM, Enis Söztutar  wrote:
 
 Sorry for the trouble, let me revert the commit. I'll look at the 0.98
>>> RC
 as well.
 
 
 Enis
 
> On Tue, Nov 17, 2015 at 7:32 PM, Enis Söztutar 
>>> wrote:
> 
> -1.
> 
> I think this RC is also affected by HBASE-14689:
> 
> 
> A run of
> 
> bin/hbase pe  --latency --nomapred --presplit=10 --valueSize=10
> randomWrite 10
> 
> results in client hang and a lot of following exceptions.
> 
> Interesting that, I cannot reproduce this with LTT.
> 
> java.io.IOException: Timed out waiting for lock for row:
>>> 075868
>   at
>>> org.apache.hadoop.hbase.regionserver.HRegion.getRowLockInternal(HRegion.java:5088)
>   at
>>> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2980)
>   at
>>> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2838)
>   at
>>> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2780)
>   at
>>> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:692)
>   at
>>> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:654)
>   at
>>> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2036)
>   at
>>> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32303)
>   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2117)
>   at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104)
>   at
>>> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
>   at
>>> org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
>   at java.lang.Thread.run(Thread.java:745)
> 
> 
> On Mon, Nov 16, 2015 at 8:35 PM, Andrew Purtell 
> wrote:
> 
>> +1
>> 
>> Checked signature and sums
>> Unpacked binary and source tarballs, contents look good
>> Built from source
>> RAT check passes
>> Loaded 1M rows with LoadTestTool, no unexpected log messages, reported
>> latencies in line with expectations
>> Ran IntegrationTestBigLinkedList, no errors
>> 
>> 
>>> On Sun, Nov 8, 2015 at 8:54 PM, Nick Dimiduk 
>>> wrote:
>>> 
>>> I'm happy to announce the first release candidate of HBase 1.1.3
>>> (HBase-1.1.
>>> 3RC0) is available for download at
>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.3RC0/
>>> 
>>> Maven artifacts are also available in the staging repository
>>> https://repository.apache.org/content/repositories/orgapachehbase-1117
>>> 
>>> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
>>> available in the Apache keys directory
>>> https://people.apache.org/keys/committer/ndimiduk.asc
>>> 
>>> There's also a signed tag for this release at
>>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=16e905679e2dd5cb1b05ca8bc34a403e154a395f
>>> 
>>> The detailed source and binary compatibility report vs 1.1.0 has been
>>> published for your review, at
>>> http://people.apache.org/~ndimiduk/1.1.0_1.1.3RC0_compat_report.html
>>> 
>>> HBase 1.1.3 is the third patch release in the HBase 1.1 line,
>> continuing on
>>> the theme of bringing a stable, reliable database to the Hadoop and
>> NoSQL
>>> communities. This release includes over 120 bug fixes since the 1.1.2
>>> release. Notable

[jira] [Reopened] (HBASE-14655) Narrow the scope of doAs() calls to region observer notifications for compaction

2015-12-06 Thread Nick Dimiduk (JIRA) 

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

Nick Dimiduk reopened HBASE-14655:
--

This patch ({{b19daf4c}}) introduces source incompatible changes to the 
{{Store}} interface on branch-1.1. Please see the [compatibility 
report|http://home.apache.org/~ndimiduk/1.1.0_branch-1.1_compat_report.html] 
for details.

> Narrow the scope of doAs() calls to region observer notifications for 
> compaction
> 
>
> Key: HBASE-14655
> URL: https://issues.apache.org/jira/browse/HBASE-14655
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16
>
> Attachments: 14655-0.98-v9.txt, 14655-0.98-v9.txt, 
> 14655-addendum.txt, 14655-branch-1-v5.txt, 14655-branch-1-v6.txt, 
> 14655-branch-1-v7.txt, 14655-branch-1-v8.txt, 14655-branch-1-v9.txt, 
> 14655-branch-1.0-v10.txt, 14655-branch-1.0-v6.txt, 14655-branch-1.0-v7.txt, 
> 14655-branch-1.0-v8.txt, 14655-branch-1.0-v9.txt, 14655-v1.txt, 14655-v2.txt, 
> 14655-v3.txt, 14655-v4.txt, 14655-v5.txt, 14655-v6.txt, 14655-v7.txt, 
> 14655-v8.txt, 14655-v9.txt
>
>
> As what has been done in HBASE-14631 and HBASE-14605, the scope of calling 
> doAs() for compaction related region observer notifications should be 
> narrowed.
> User object is passed from CompactSplitThread down to the methods where 
> region observer notifications are made.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (HBASE-14605) Split fails due to 'No valid credentials' error when SecureBulkLoadEndpoint#start tries to access hdfs

2015-12-06 Thread Nick Dimiduk (JIRA) 

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

Nick Dimiduk reopened HBASE-14605:
--

This patch ({{c14233b4}}) introduces source incompatible changes to the 
{{SplitTransaction}} interface on branch-1.1. Please see the [compatibility 
report|http://home.apache.org/~ndimiduk/1.1.0_branch-1.1_compat_report.html] 
for details.

> Split fails due to 'No valid credentials' error when 
> SecureBulkLoadEndpoint#start tries to access hdfs
> --
>
> Key: HBASE-14605
> URL: https://issues.apache.org/jira/browse/HBASE-14605
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16
>
> Attachments: 144605-branch-1-v3.txt, 14605-0.98-v5.txt, 
> 14605-branch-1-addendum.txt, 14605-branch-1-v4.txt, 14605-branch-1-v5.txt, 
> 14605-branch-1.0-v5.txt, 14605-v1.txt, 14605-v2.txt, 14605-v3.txt, 
> 14605-v3.txt, 14605-v3.txt, 14605-v4.txt, 14605-v5.txt, 14605.alt
>
>
> During recent testing in secure cluster (with HBASE-14475), we found the 
> following when user X (non-super user) split a table with region replica:
> {code}
> 2015-10-12 10:58:18,955 ERROR [FifoRpcScheduler.handler1-thread-9] 
> master.HMaster: Region server hbase-4-4.novalocal,60020,1444645588137 
> reported a fatal error:
> ABORTING region server hbase-4-4.novalocal,60020,1444645588137: The 
> coprocessor org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint 
> threw an unexpected   exception
> Cause:
> java.lang.IllegalStateException: Failed to get FileSystem instance
>   at 
> org.apache.hadoop.hbase.security.access.SecureBulkLoadEndpoint.start(SecureBulkLoadEndpoint.java:148)
>   at 
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:415)
>   at 
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:257)
>   at 
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadSystemCoprocessors(CoprocessorHost.java:160)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.(RegionCoprocessorHost.java:192)
>   at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:701)
>   at org.apache.hadoop.hbase.regionserver.HRegion.(HRegion.java:608)
> ...
> Caused by: java.io.IOException: Failed on local exception: 
> java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed 
> [Caused by GSSException: No valid  credentials provided (Mechanism 
> level: Failed to find any Kerberos tgt)]; Host Details : local host is: 
> "hbase-4-4/172.22.66.186"; destination host is: "os-r6-  
> okarus-hbase-4-2.novalocal":8020;
>   at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1473)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1400)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
>   at com.sun.proxy.$Proxy18.mkdirs(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.mkdirs(ClientNamenodeProtocolTranslatorPB.java:555)
>   at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
>   at com.sun.proxy.$Proxy19.mkdirs(Unknown Source)
>   at org.apache.hadoop.hdfs.DFSClient.primitiveMkdir(DFSClient.java:2775)
>   at org.apache.hadoop.hdfs.DFSClient.mkdirs(DFSClient.java:2746)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:967)
>   at 
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:963)
>   at 
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> {code}
> The cause was that SecureBulkLoadEndpoint#start tried to create staging dir 
> in hdfs as user X but didn't pass authentication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] First release candidate for HBase 1.1.3 (RC0) is available

2015-12-06 Thread Nick Dimiduk 
I found some source-incompatible changes in the compatibility report [0].
Reopened HBASE-14605, HBASE-14655, and HBASE-14631 as blockers for 1.1.x
and 1.0.x. Since I'm asking, would be good to see the last mile
on HBASE-14822 and HBASE-14844.

[0]:
http://home.apache.org/~ndimiduk/1.1.0_branch-1.1_compat_report.html#Type_Source_Problems_High

On Wed, Dec 2, 2015 at 1:17 PM, Nick Dimiduk  wrote:

> With HBASE-14689 resolved, I plan to spin the next RC this weekend. Let me
> know if you have any concerns.
>
> -n
>
> On Tue, Nov 17, 2015 at 8:33 PM, Andrew Purtell 
> wrote:
>
>> Let's revert this from 0.98 even if the problem isn't manifesting there
>> (or perhaps just not in the same way)
>>
>>
>> > On Nov 17, 2015, at 7:33 PM, Enis Söztutar  wrote:
>> >
>> > Sorry for the trouble, let me revert the commit. I'll look at the 0.98
>> RC
>> > as well.
>> >
>> >
>> > Enis
>> >
>> >> On Tue, Nov 17, 2015 at 7:32 PM, Enis Söztutar 
>> wrote:
>> >>
>> >> -1.
>> >>
>> >> I think this RC is also affected by HBASE-14689:
>> >>
>> >>
>> >> A run of
>> >>
>> >> bin/hbase pe  --latency --nomapred --presplit=10 --valueSize=10
>> >> randomWrite 10
>> >>
>> >> results in client hang and a lot of following exceptions.
>> >>
>> >> Interesting that, I cannot reproduce this with LTT.
>> >>
>> >> java.io.IOException: Timed out waiting for lock for row:
>> 075868
>> >>at
>> org.apache.hadoop.hbase.regionserver.HRegion.getRowLockInternal(HRegion.java:5088)
>> >>at
>> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2980)
>> >>at
>> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2838)
>> >>at
>> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2780)
>> >>at
>> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:692)
>> >>at
>> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:654)
>> >>at
>> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2036)
>> >>at
>> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32303)
>> >>at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2117)
>> >>at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:104)
>> >>at
>> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
>> >>at
>> org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
>> >>at java.lang.Thread.run(Thread.java:745)
>> >>
>> >>
>> >> On Mon, Nov 16, 2015 at 8:35 PM, Andrew Purtell 
>> >> wrote:
>> >>
>> >>> +1
>> >>>
>> >>> Checked signature and sums
>> >>> Unpacked binary and source tarballs, contents look good
>> >>> Built from source
>> >>> RAT check passes
>> >>> Loaded 1M rows with LoadTestTool, no unexpected log messages, reported
>> >>> latencies in line with expectations
>> >>> Ran IntegrationTestBigLinkedList, no errors
>> >>>
>> >>>
>>  On Sun, Nov 8, 2015 at 8:54 PM, Nick Dimiduk 
>> wrote:
>> 
>>  I'm happy to announce the first release candidate of HBase 1.1.3
>>  (HBase-1.1.
>>  3RC0) is available for download at
>>  https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.3RC0/
>> 
>>  Maven artifacts are also available in the staging repository
>> 
>> https://repository.apache.org/content/repositories/orgapachehbase-1117
>> 
>>  Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
>>  available in the Apache keys directory
>>  https://people.apache.org/keys/committer/ndimiduk.asc
>> 
>>  There's also a signed tag for this release at
>> >>>
>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=16e905679e2dd5cb1b05ca8bc34a403e154a395f
>> 
>>  The detailed source and binary compatibility report vs 1.1.0 has been
>>  published for your review, at
>>  http://people.apache.org/~ndimiduk/1.1.0_1.1.3RC0_compat_report.html
>> 
>>  HBase 1.1.3 is the third patch release in the HBase 1.1 line,
>> >>> continuing on
>>  the theme of bringing a stable, reliable database to the Hadoop and
>> >>> NoSQL
>>  communities. This release includes over 120 bug fixes since the 1.1.2
>>  release. Notable correctness fixes
>>  include HBASE-14474, HBASE-14591, HBASE-14224,
>>  HBASE-14431, HBASE-14407, HBASE-14313, HBASE-14621, HBASE-14501, and
>>  HBASE-13250.
>> 
>>  The full list of fixes included in this release is available at
>> >>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753=12333152
>>  and in the CHANGES.txt file included in the distribution.
>> 
>>  Please try out this candidate and vote +/-1 by 23:59 Pacific time on
>>  Friday, 2015-11-13 as to whether we should release these

[jira] [Reopened] (HBASE-14631) Region merge request should be audited with request user through proper scope of doAs() calls to region observer notifications

2015-12-06 Thread Nick Dimiduk (JIRA) 

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

Nick Dimiduk reopened HBASE-14631:
--

This patch ({{a5759d39}}) introduces source incompatible changes to the 
{{SplitTransaction}} interface on branch-1.1. Please see the [compatibility 
report|http://home.apache.org/~ndimiduk/1.1.0_branch-1.1_compat_report.html] 
for details.

> Region merge request should be audited with request user through proper scope 
> of doAs() calls to region observer notifications
> --
>
> Key: HBASE-14631
> URL: https://issues.apache.org/jira/browse/HBASE-14631
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16
>
> Attachments: 14631-branch-0.98.txt, 14631-branch-1.0.txt, 
> 14631-branch-1.txt, 14631-v1.txt, HBASE-14631-addendum.patch
>
>
> HBASE-14475 and HBASE-14605 narrowed the scope of doAs() calls to region 
> observer notifications for region splitting.
> During review of HBASE-14605, Andrew brought up the case for region merge.
> This JIRA is to implement similar scope narrowing technique for region 
> merging.
> The majority of the change would be in RegionMergeTransactionImpl class.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-14934) Applying PrefixFilter to a scan should implicitly limit startrow

2015-12-06 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-14934:


 Summary: Applying PrefixFilter to a scan should implicitly limit 
startrow
 Key: HBASE-14934
 URL: https://issues.apache.org/jira/browse/HBASE-14934
 Project: HBase
  Issue Type: Improvement
  Components: Filters
Reporter: Nick Dimiduk
Priority: Minor


As was mentioned over on HBASE-14928, client setting a {{PrefixFilter}} should 
imply a startrow on the scan.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Would ROWCOL Bloom filter help in Scan

2015-12-06 Thread larsh 
We already use the ROWCOL BF for the ExplicitColumnTracker.See HBASE-8362 for 
my _failed_ attempt a while back to use ROW BFs to optimize seeking a scanner.
-- Lars
  From: Jerry He 
 To: dev  
 Sent: Saturday, December 5, 2015 12:54 PM
 Subject: Re: Would ROWCOL Bloom filter help in Scan
   
>
> It has to have a row on it, right?


Only the column name is the key in the bloom.  For explicit columnar scan
only.
StoreFileScanner can be skipped after this bloom check.
Only a high level thinking here.  No?  It does't work this way?  I must
miss something then.



> And how do we get space savings?



The number of columns would be much less than the ROW+COL


> There is a bloom at the start of every row already, to speed deletes. IIRC,
> we always read this first before we do anything. Perhaps we could beef it
> up with more than just delete?
>

Have seen something like that in the code. Still trying to better
understand it.





>
> St.Ack
>
>
>
> > Jerry
> >
> > On Thu, Dec 3, 2015 at 9:01 AM, Stack  wrote:
> >
> > > On Wed, Dec 2, 2015 at 10:01 PM, Jerry He  wrote:
> > >
> > > > Thanks for the response.  You got my question correctly.
> > > > If we are scanning the rows one by one and we have the requested
> column
> > > in
> > > > the column tracker, we have the row+column to look up in the bloom
> > > filter,
> > > > don't we? We may not be able to filter out the file scanners upfront.
> > But
> > > > may at the later time and lower level to skip something?
> > > >
> > > >
> > > You are right. If more than one explicit
> > > column specified, we could do a bloom check for the second and so on
> > since
> > > we'd have the current row to hand. It could make for a nice speedup for
> > > scans of many explicit columns traversing a dataset that is sparsely
> > > populated..
> > >
> > > St.Ack
> > >
> > >
> > >
> > > > Jerry
> > > >
> > > > On Mon, Nov 30, 2015 at 10:55 PM, Stack  wrote:
> > > >
> > > > > On Mon, Nov 30, 2015 at 9:56 AM, Jerry He 
> > wrote:
> > > > >
> > > > > > Hi, experts
> > > > > >
> > > > > > HBASE supports ROWCOL bloom filter. ROW+COL would be the bloom
> key.
> > > > > > In most of the documentations, it says only GET would benefit.
> For
> > > > > > multi-column as well.
> > > > > >
> > > > > > If I do scan with StartRow and EndRow, and also specify columns.
> > > > > > Would ROWCOL bloom filter provide any benefit in anyway?
> > > > > >
> > > > > >
> > > > > If I understand your question properly, the answer is no. While we
> > > might
> > > > > have a set of columns to check in the bloom, we'd not know the set
> of
> > > > rows
> > > > > between start and end row and so would not be able to formulate a
> > query
> > > > > against the ROW+COL bloom filter.
> > > > >
> > > > > St.Ack
> > > > >
> > > > >
> > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Jerry
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (HBASE-14933) check_compatibility.sh does not work with jdk8

2015-12-06 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-14933:


 Summary: check_compatibility.sh does not work with jdk8
 Key: HBASE-14933
 URL: https://issues.apache.org/jira/browse/HBASE-14933
 Project: HBase
  Issue Type: Task
  Components: scripts
Reporter: Nick Dimiduk
Priority: Minor
 Fix For: 2.0.0


Specifically, Oracle jdk1.8.0_65 on OSX and OpenJDk 1.8.0_45-internal-b14 on 
ubuntu.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-14935) StoreScanner.peek() should reset the heap if the heap was nullified

2015-12-06 Thread ramkrishna.s.vasudevan (JIRA) 
ramkrishna.s.vasudevan created HBASE-14935:
--

 Summary: StoreScanner.peek() should reset the heap if the heap was 
nullified
 Key: HBASE-14935
 URL: https://issues.apache.org/jira/browse/HBASE-14935
 Project: HBase
  Issue Type: Bug
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0


StoreScanner#peek(), after HBASE-13082, check if the heap was reset. If the 
heap is null it just returns the last top. Instead it should do a reset and 
then return the last top if still the heap was null. 
Similar change is needed in ReversedStoreScanner#seekToPreviousRow and 
backwardSeek



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: Consesus on removing a public method from IA.Private class whose instance is returned from IA.public class.

2015-12-06 Thread ashish singhi 
Sorry for the late response. I was on vacation.

St.Ack: 
Class 'A' is HBaseAdmin and class 'B' is HBaseTestingUtility.
I was thinking this from a general perspective, irrespective of the classes and 
can note it down in our book and avoid this kind of discussions in dev mailing 
list in future. But seems like we have agreed to take up the call based on the 
particulars.

Regards,
Ashish Singhi

-Original Message-
From: saint@gmail.com [mailto:saint@gmail.com] On Behalf Of Stack
Sent: 03 December 2015 06:07
To: HBase Dev List
Subject: Re: Consesus on removing a public method from IA.Private class whose 
instance is returned from IA.public class.

Appy makes a pretty good argument.

What in particular are we discussing Ashish?

Thanks,
St.Ack

On Wed, Dec 2, 2015 at 3:49 PM, Apekshit Sharma  wrote:

> I think it should be okay to remove them. When I imagine myself on 
> other side, a dev using client api of Foo project, and I see a class 
> returning reference to an internal class, I would not trust that 
> function. If I really need something from returned ref, I'd probably 
> use it, and if it goes away tomorrow, i'd probably curse it too, but I 
> can't complain since it's not anything I trusted to being with.
>
> Now thinking as dev:
> Given that documentation explicitly states that functions can 
> disappear from private class, and nothing about transitiveness, I 
> believe we can remove functions from private class A.
>
>
> On Thu, Nov 26, 2015 at 7:10 AM, Ted Yu  wrote:
>
> > bq. we should not remove it directly
> >
> > My understanding is the same.
> >
> > Cheers
> >
> > On Wed, Nov 25, 2015 at 10:22 PM, ashish singhi <
> ashish.sin...@huawei.com>
> > wrote:
> >
> > > Hello to all.
> > >
> > > I know that we can safely remove any APIs from a
> > InterfaceAudience.Private
> > > class and the same is described in the HBase book.
> > >
> > > Now consider a case (I did not find this mentioned in our semvar), 
> > > There is a class 'A' with InterfaceAudience.Private and class 'B' 
> > > with InterfaceAudience.Public and then there is a public API in class 'B'
> > which
> > > returns an instance of class 'A'. (We missed to mark the public 
> > > method
> in
> > > class 'B' as deprecated when we marked the class 'A' as 
> > > InterfaceAudience.Private).
> > >
> > > Now the question is, can we remove the public APIs from class 'A'
> without
> > > marking them deprecated ?
> > >
> > > I think we should not remove it directly, it will break the users 
> > > using
> > > these(removed) public methods from class 'A'.
> > > P.S: This point came up  in HBASE-14769.
> > >
> > > Regards,
> > > Ashish Singhi
> > >
> >
>
>
>
> --
>
> Regards
>
> Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California 
> |
> 650-963-6311
>