[RESULT][VOTE] Second release candidate for HBase 1.1.3 (RC1) is available

2016-01-25 Thread Nick Dimiduk 
With 3 +1 votes and no 0 or -1 votes, this vote has passed. I will process
these artifacts for distribution as 1.1.3 momentarily. Thanks again for
everyone who took time to review the candidates this release.

Thanks,
Nick

On Mon, Jan 25, 2016 at 9:40 PM, Nick Dimiduk  wrote:

> +1
>
> - verified tarballs vs public key in p.a.o/keys/committers/ndimiduk.asc.
> - extracted bin tgz:
>   - inspect structure. look good.
>   - run LoadTestTool against standalone built from src tgz with FAST_DIFF
> block encoder and ROWCOL blooms. No issues, logs look good.
>   - poked around webUI. looks good.
>   - load the site, browsed book and API docs.
> - extracted src tgz:
>   - built, ran tests; filed a couple subtasks under HBASE-15168
>   - inspect structure. look good.
>   - run LoadTestTool against standalone built from src tgz with FAST_DIFF
> block encoder and ROWCOL blooms. No issues, logs look good.
>   - poked around webUI. looks good.
> - inspected compatibility report. Issues look acceptable as per our
> policies.
>
> On Mon, Jan 25, 2016 at 7:16 PM, Nick Dimiduk  wrote:
>
>> Yes Andrew, that's my conclusion as well. I will evaluate the bits for
>> myself this evening. I'll also dig into the test results from my weekend
>> runs.
>>
>>
>> On Monday, January 25, 2016, Andrew Purtell  wrote:
>>
>>> Hi Nick,
>>>
>>> Perhaps the silence in response to your inquiry and lack of vetos to date
>>> can be interpreted as consensus to move forward. There are 2 +1 votes
>>> already. If you decide to cast a third positive vote, we can release.
>>>
>>>
>>> On Thu, Jan 21, 2016 at 2:32 PM, Nick Dimiduk 
>>> wrote:
>>>
>>> > > TestDurability is failing in branch-1.1 with a small issue and have
>>> just
>>> > filed HBASE-15150 to fix it, JFYI.
>>> >
>>> > Thanks a lot Yu Li, I'll take a look.
>>> >
>>> > > I'm seeing that TestDurability failure as well, and am also finding
>>> that
>>> > TestWALLockup frequently times out and fails when running the unit test
>>> > suite with 7u79.
>>> >
>>> > Thanks for checking guys. This release line has not had the diligent
>>> > attention to test stability that later branches have. Indeed this
>>> point was
>>> > raised around earlier release from this branch as well. Previously we
>>> were
>>> > simply disabling flakey tests on this branch as bandwidth was not
>>> available
>>> > to fix them and they withheld release. I've depended more on CM
>>> testing to
>>> > verify bits and less on UT harness with far with branch-1.1. It is my
>>> > intention to organize efforts around backporting test fixes (ie,
>>> > from HBASE-14420), though I see no reason to withhold further patch
>>> > releases in the mean time. This patch release is *months* over due.
>>> >
>>> > I am of course acting on the PMC's behalf as release manager. I will
>>> defer
>>> > to the PMC judgement on whether this UT situation constitutes
>>> acceptable
>>> > parameters for release. I will absolutely accept community assistance
>>> in
>>> > bring this branch's UT runs back into the green; it's not an effort I'm
>>> > able to tackle solo in any timely manor.
>>> >
>>> > -n
>>> >
>>> > On Thu, Jan 21, 2016 at 11:36 AM, Andrew Purtell 
>>> > wrote:
>>> >
>>> > > I'm seeing that TestDurability failure as well, and am also finding
>>> that
>>> > > TestWALLockup frequently times out and fails when running the unit
>>> test
>>> > > suite with 7u79.
>>> > >
>>> > > The LICENSE.txt file in the binary tarball has some unsubstituted
>>> > > "${dep.licenses[0].comments}" for Apache Commons Collections and
>>> Netty. I
>>> > > think this is only a nit because right above where the substitutions
>>> fail
>>> > > we indicate in both cases the dependency is ASL 2.0 licensed and the
>>> text
>>> > > of that license appears elsewhere in the file.
>>> > >
>>> > > I'll defer to the RM if the above should sink the RC.
>>> > >
>>> > > Otherwise,
>>> > > - Signatures and checksums look good
>>> > > - Tarball structure looks good
>>> > > - Build from source with release auditing enabled passes
>>> > > - Ran LTT against a minicluster, loaded 1M rows (and updating 20%),
>>> no
>>> > > errors, no unusual or unexpected messages in the logs, and reported
>>> > > latencies are roughly as expected
>>> > >
>>> > > +1
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Jan 21, 2016 at 5:23 AM, Yu Li  wrote:
>>> > >
>>> > > > Hi Nick,
>>> > > >
>>> > > > TestDurability is failing in branch-1.1 with a small issue and have
>>> > just
>>> > > > filed HBASE-15150 to fix it, JFYI.
>>> > > >
>>> > > > Best Regards,
>>> > > > Yu
>>> > > >
>>> > > > On 21 January 2016 at 06:33, Enis Söztutar 
>>> wrote:
>>> > > >
>>> > > > > Thanks Nick for putting the RC together.
>>> > > > >
>>> > > > > Here is my +1.
>>> > > > >
>>> > > > > - checked crcs, sigs.
>>> > > > >
>>> > > > > - checked tarball layouts, files, jar files, etc.
>>> > > > >
>>> >

[jira] [Resolved] (HBASE-15162) Add separate metrics for meta/data block hit ratio in cache

2016-01-25 Thread Yu Li (JIRA) 

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

Yu Li resolved HBASE-15162.
---
Resolution: Duplicate

> Add separate metrics for meta/data block hit ratio in cache
> ---
>
> Key: HBASE-15162
> URL: https://issues.apache.org/jira/browse/HBASE-15162
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Yu Li
>Assignee: Yu Li
> Attachments: HBASE-15162.patch, HBASE-15162_v2.patch
>
>
> Currently we already have a metrics in name of 
> {{blockCacheExpressHitPercent}} to indicate the cache hit ratio. However, 
> since meta block is small and often cached in memory with a high hit ratio, 
> this "mixed" metrics could not show the real data block hit ratio which is 
> more concerned.
> We propose to add two new metrics to show meta and data block cache hit ratio 
> separately, while reserving the old metrics for backward compatibility.



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

[jira] [Created] (HBASE-15167) Deadlock in TestNamespaceAuditor.testRegionOperations on 1.1

2016-01-25 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-15167:


 Summary: Deadlock in TestNamespaceAuditor.testRegionOperations on 
1.1
 Key: HBASE-15167
 URL: https://issues.apache.org/jira/browse/HBASE-15167
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.1.3
Reporter: Nick Dimiduk


This was left as a zombie after one of my test runs this weekend. 

{noformat}
"WALProcedureStoreSyncThread" daemon prio=10 tid=0x7f3ccc209000 nid=0x3960 
in Object.wait() [0x7f3c6b6b5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:503)
at org.apache.hadoop.ipc.Client.call(Client.java:1397)
- locked <0x0007f2813390> (a org.apache.hadoop.ipc.Client$Call)
at org.apache.hadoop.ipc.Client.call(Client.java:1364)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)
at com.sun.proxy.$Proxy23.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor25.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.$Proxy23.create(Unknown Source)
at 
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.create(ClientNamenodeProtocolTranslatorPB.java:264)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:279)
at com.sun.proxy.$Proxy24.create(Unknown Source)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.hbase.fs.HFileSystem$1.invoke(HFileSystem.java:279)
at com.sun.proxy.$Proxy24.create(Unknown Source)
at 
org.apache.hadoop.hdfs.DFSOutputStream.newStreamForCreate(DFSOutputStream.java:1612)
at org.apache.hadoop.hdfs.DFSClient.create(DFSClient.java:1488)
at org.apache.hadoop.hdfs.DFSClient.create(DFSClient.java:1413)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$6.doCall(DistributedFileSystem.java:387)
at 
org.apache.hadoop.hdfs.DistributedFileSystem$6.doCall(DistributedFileSystem.java:383)
at 
org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.create(DistributedFileSystem.java:383)
at 
org.apache.hadoop.hdfs.DistributedFileSystem.create(DistributedFileSystem.java:327)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:906)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:887)
at org.apache.hadoop.fs.FileSystem.create(FileSystem.java:784)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.rollWriter(WALProcedureStore.java:766)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.rollWriter(WALProcedureStore.java:733)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.tryRollWriter(WALProcedureStore.java:668)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.periodicRoll(WALProcedureStore.java:711)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.syncLoop(WALProcedureStore.java:531)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.access$000(WALProcedureStore.java:66)
at 
org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore$1.run(WALProcedureStore.java:180)
{noformat}



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

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Nick Dimiduk 
Did I get the 1.1.3 release tag correct?

On Mon, Jan 25, 2016 at 3:32 PM, Andrew Purtell  wrote:

> I see.
>
> The release tags I pushed are not signed.
>
> On Mon, Jan 25, 2016 at 3:30 PM, Sean Busbey  wrote:
>
> > To date the only signing has been on release tags. AFAIK, signed tags are
> > only visible using "git show":
> >
> > ex:
> >
> > $ git show 1.0.0
> > tag 1.0.0
> > Tagger: Enis Soztutar 
> > Date:   Sat Feb 21 14:32:18 2015 -0800
> >
> > Tag 1.0.0
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> >
> > iQIcBAABCgAGBQJU6Qd4AAoJEAhFjDnpZLX/TvkP/2qrbuvm2Fp7ifrhZ5pngApl
> > plrI6yWUaXIS9cFj3fvInoXZ7CvKGSs6+ixngRsQBoYHvH1Lgu8SGcPVn5wj54WJ
> > bnwnhlvsfp3NQ1/UuADqCYPb8xRkHdijMnCxeRyZPGR3piZSCN8MwTSsdKbIJU8u
> > XCyDgFVx3IEOpphCDytZu5gZ6pRnvJfm3SqAjXC86/h8eTRvMwdbV1SwePWNA5HQ
> > CMHUBkLm4Nw8xD0Z7AdsKb+GxeM2P/xtN+ETQI0mOXJ9aWfsDQaGsMi4DXQRBGeT
> > h3Q/r6lImOjBqAnMeny3JLy3OIpDhFk7ezm2L7zwzaCgCGjWOcN/G7mmJkkl/i18
> > 0MKKij7CPDP3yKfkhZs1HW68FalIaJ/kTQsRHIFOR+leVrB4xnaa2bx42lkWouqC
> > 329qtubrGYN8jzqHSjoV5GvlAxz4tWdKz97N+WaBouzrQNkfAwkW9Kr/Cgr8XxQG
> > h+CxPJN8NEWdQKzEK6ibeGjCp8ULKfhuPUtIq3U/9vnFs4gtt0I6AQo5VeWxpePu
> > 7BO1utwlWSQExMb5ES7fbwabh26yd9ZIfELpx7Ek3HR9jCEu7rE0pneKHUEFGR0d
> > +hXlYua9wcKmcftu4Q1nnz+tFFtCv9uosxWRMFHN/0RAw67rQ2D/hqS4vpnNsOQF
> > rjvbLk7ASDRbjD15WxXj
> > =ef23
> > -END PGP SIGNATURE-
> >
> > commit 6c98bff7b719efdb16f71606f3b7d8229445eb81
> > Author: Enis Soztutar 
> > Date:   Sat Feb 14 19:41:51 2015 -0800
> >
> > SNIP...
> >
> > $  git show 1.1.2
> > tag 1.1.2
> > Tagger: Nick Dimiduk 
> > Date:   Tue Sep 1 09:15:22 2015 -0700
> >
> > Tag 1.1.2
> > -BEGIN PGP SIGNATURE-
> >
> > iQIcBAABCgAGBQJV5c8aAAoJEK2QOQccNIm9wjUQAIcZLsjYEKVohQJq5Wp3ZcrD
> > Z8dN265BIG1/IyBvvVYDEKQljWXeb5sIYxjoE0jVkiC80IWKmRKVgmR1K+lElPyR
> > Jx39ea+tNUKfrVj+vGN+3xOlLsc2RT+9x9EhKL+X38ZUUD7P0bSlcQvCekYFc0Ik
> > 61VZDF24VXL4dvudahpOf+1mfQam9Ij4bEtwSe7tK8BSd1+FaPQKatEK5UqUAf+d
> > TTi3dnsoyZKOgiaSesZ6QbocBhB7h68ormnY9dowkCdr6CK/qXuNlCYNqtJx3EKQ
> > a0UsqbQNLimGANtO1llU8DiTbcS113z0SEiFyn4b/MuM8VtUQgMiLJx44o0ZhUB9
> > GDzXXMdMM7xkJjc7mUT5kxyqwsAo+G5MtaAS2gkMeeF4l5sZ+xT+DUKWfwfVBe0D
> > cg4JhhbX6/O4Nis92CQTbVLfgtF/K20cph5J7JiIf7wT+vkF2sIpb04INMCF/c+D
> > P5XGQt8UJ+Lewiln2E56UOOjRKZdj2JXBEOkiXXFledoXuGsBHWLUi0vL6FmmsZN
> > nd27SSsA/4cJerV4N91ekeqJ343oc6SYYuevfiTa6TIB2I9qRn7bLBFMedlzLSvt
> > 0sKUgZvK3oDtOJ0N3gk+TkvXiHSBZQIpWw9H4hUXh+Vx5C+0FD+sGMSGea+md+b+
> > YHyDoviUo72QtexwuS5c
> > =I+Z4
> > -END PGP SIGNATURE-
> > ...SNIP...
> >
> > On Mon, Jan 25, 2016 at 5:22 PM, Andrew Purtell 
> > wrote:
> >
> > > I have made new refs in rel/ pointing to the same SHA as the earlier
> tag
> > > and pushed them.
> > >
> > > I don't believe any committers have or are planning to make PGP signed
> > > commits. I also made a quick check with 'git log' of recent release
> refs
> > > and did not find signed commits. That is a practice we could adopt. I'd
> > be
> > > supportive of that. All committers would need to do so to make it
> > > worthwhile.
> > >
> > >
> > > On Mon, Jan 25, 2016 at 3:01 PM, Sean Busbey 
> > wrote:
> > >
> > > > one question: will the new historic tags have your PGP signature
> rather
> > > > than the original RM(s)? If so, do we need to make a note of the
> cause
> > of
> > > > this discrepancy?
> > > >
> > > > A vote in favor of leaving the old tags: since we've been treating
> > > release
> > > > tags as permalinks (regardless of their actual mutable state), folks
> > are
> > > > likely to have links to them saved places.
> > > >
> > > > On Mon, Jan 25, 2016 at 3:26 PM, Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > Question: Would you like me to clean up afterward by pushing
> deletes
> > > for
> > > > > the soon-to-be duplicate release tags? No rush on an answer. I'll
> > wait
> > > a
> > > > > few days for responses to come in.
> > > > >
> > > > > On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell <
> apurt...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > I'll be adding tags under refs/rel/ for all previous HBase
> releases
> > > > > today,
> > > > > > using a snapshot of HBase's Apache git repository last updated at
> > > > Monday
> > > > > > January 25 13:20:47 PST 2016.
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > >- Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back. -
> Piet
> > > > Hein
> > > > > > (via Tom White)
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >- Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sean
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack

[jira] [Resolved] (HBASE-15166) Remove delayed rpc

2016-01-25 Thread Elliott Clark (JIRA) 

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

Elliott Clark resolved HBASE-15166.
---
Resolution: Duplicate

> Remove delayed rpc
> --
>
> Key: HBASE-15166
> URL: https://issues.apache.org/jira/browse/HBASE-15166
> Project: HBase
>  Issue Type: Bug
>Reporter: Elliott Clark
>
> It's a feature that's not used and makes our RPC much more complex than is 
> necessary.



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

[jira] [Created] (HBASE-15166) Remove delayed rpc

2016-01-25 Thread Elliott Clark (JIRA) 
Elliott Clark created HBASE-15166:
-

 Summary: Remove delayed rpc
 Key: HBASE-15166
 URL: https://issues.apache.org/jira/browse/HBASE-15166
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark


It's a feature that's not used and makes our RPC much more complex than is 
necessary.



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

[jira] [Created] (HBASE-15168) Zombie stomping branch-1.1 edition

2016-01-25 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-15168:


 Summary: Zombie stomping branch-1.1 edition
 Key: HBASE-15168
 URL: https://issues.apache.org/jira/browse/HBASE-15168
 Project: HBase
  Issue Type: Umbrella
  Components: test
Affects Versions: 1.1.0
Reporter: Nick Dimiduk
Priority: Critical
 Fix For: 1.1.4


Let's bring back the work done on HBASE-14420 for branch-1.1, stabilize our 
[builds|https://builds.apache.org/job/HBase-1.1-JDK7/]. Hang tickets here.



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

Re: [VOTE] Second release candidate for HBase 1.0.3 (RC1) is available. Please vote by Jan 26 2016

2016-01-25 Thread Enis Söztutar 
Tomorrow is the last day for this RC voting. Can we get some more votes
please. This will be the last scheduled release in 1.0 line.

Thanks,
Enis

On Mon, Jan 25, 2016 at 1:33 PM, Enis Söztutar  wrote:

> Here is the UT build for the RC:
>
>
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-1.0.3RC1/2/testReport/
>
> All tests passed on the second run.
>
> Enis
>
> On Sat, Jan 23, 2016 at 8:00 PM, Enis Söztutar  wrote:
>
>> Gently reminder for the vote.
>>
>> On Wed, Jan 20, 2016 at 2:40 PM, Enis Söztutar  wrote:
>>
>>> Here is my official +1. I executed the same tests from 1.1.3RC for
>>> 1.0.3RC.
>>>
>>> - checked crcs, sigs.
>>>
>>> - checked tarball layouts, files, jar files, etc.
>>>
>>> - checked the book in the bin tar
>>>
>>> - checked versions reported
>>>
>>> - checked the compat report
>>>
>>> - compiled with Hadoop 2.2 to 2.7
>>>
>>> - build with hbase-downstreamer
>>>
>>> - run local model, shell smoke tests, LTT.
>>>
>>> - Put it up on a 4 node cluster, ran LTT.
>>>
>>>
>>> Everything looks nominal.
>>>
>>> On Tue, Jan 19, 2016 at 8:29 PM, Enis Söztutar  wrote:
>>>
 I am pleased to announce that the second release candidate for the
 release 1.0.3
 (HBase-1.0.3RC1), is available for download at
 https://dist.apache.org/repos/dist/dev/hbase/hbase-1.0.3RC1/

 Maven artifacts are also available in the temporary repository
 https://repository.apache.org/content/repositories/orgapachehbase-1126


 Signed with my code signing key E964B5FF. Can be found here:
 https://people.apache.org/keys/committer/enis.asc

 Signed tag in the repository can be found here:
 https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=45baeb796eb98676b4b45f2d29ed1bd595e26cb7

 HBase 1.0.3 is the next “patch” release in the 1.0.x release line and
 supersedes all previous 1.0.x releases. According to the HBase’s semantic
 version guide (See [1]), the release candidate is source and binary
 compatible with 1.0.x for client applications and server side libraries
 (coprocessors, filters, etc).

 Please note that 1.0.3 is the last “scheduled” release in the 1.0.x
 line of releases since there is a limited amount of testing and release
 management bandwidth. Users are highly encouraged to upgrade to 1.1 line of
 releases if possible. However, if there is enough interest, or needed
 otherwise, we can still decide to do more releases. Please be encouraged to
 speak up if you want us to continue scheduled 1.0.x releases. See the
 hbase-dev mailing thread [6] for more information.

 Binary / source compatibility report of 1.0.3RC1 compared to 1.0.2 can
 be reached here:
 https://home.apache.org/~enis/1.0.2_1.0.3RC1_compat_report.html

 1.0.3 release contains 102 fixes on top of 1.0.2 release. Most of
 the changes are
 bug fixes or test fixes except for the following:

 ** Sub-task
 * [HBASE-14221] - Reduce the number of time row comparison is done
 in a Scan
 * [HBASE-14535] - Integration test for rpc connection concurrency /
 deadlock testing·
 * [HBASE-14539] - Slight improvement of StoreScanner.optimize
 * [HBASE-14605] - Split fails due to 'No valid credentials' error
 when SecureBulkLoadEndpoint#start tries to access hdfs
 * [HBASE-14631] - Region merge request should be audited with
 request user through proper scope of doAs() calls to region observer
 notifications
 * [HBASE-14655] - Narrow the scope of doAs() calls to region
 observer notifications for compaction
 * [HBASE-14657] - Remove unneeded API from EncodedSeeker
 * [HBASE-14709] - Parent change breaks graceful_stop.sh on a
 cluster
 * [HBASE-15031] - Fix merge of MVCC and SequenceID performance
 regression in branch-1.0
 * [HBASE-15095] - isReturnResult=false  on fast path in branch-1.1
 and branch-1.0 is not respected

 ** Brainstorming
 * [HBASE-14869] - Better request latency and size histograms

 ** Improvement
 * [HBASE-14261] - Enhance Chaos Monkey framework by adding
 zookeeper and datanode fault injections.
 * [HBASE-14325] - Add snapshotinfo command to hbase script
 * [HBASE-14436] - HTableDescriptor#addCoprocessor will always make
 RegionCoprocessorHost create new Configuration
 * [HBASE-14582] - Regionserver status webpage bucketcache list can
 become huge
 * [HBASE-14586] - Use a maven profile to run Jacoco analysis
 * [HBASE-14643] - Avoid Splits from once again opening a closed
 reader for fetching the first and last key

 ** Task
 * [HBASE-14361] - ReplicationSink should create Connection
 instances lazily


 Full list of the issues can be found at

Re: [VOTE] Second release candidate for HBase 1.1.3 (RC1) is available

2016-01-25 Thread Nick Dimiduk 
+1

- verified tarballs vs public key in p.a.o/keys/committers/ndimiduk.asc.
- extracted bin tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
  - load the site, browsed book and API docs.
- extracted src tgz:
  - built, ran tests; filed a couple subtasks under HBASE-15168
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with FAST_DIFF
block encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
- inspected compatibility report. Issues look acceptable as per our
policies.

On Mon, Jan 25, 2016 at 7:16 PM, Nick Dimiduk  wrote:

> Yes Andrew, that's my conclusion as well. I will evaluate the bits for
> myself this evening. I'll also dig into the test results from my weekend
> runs.
>
>
> On Monday, January 25, 2016, Andrew Purtell  wrote:
>
>> Hi Nick,
>>
>> Perhaps the silence in response to your inquiry and lack of vetos to date
>> can be interpreted as consensus to move forward. There are 2 +1 votes
>> already. If you decide to cast a third positive vote, we can release.
>>
>>
>> On Thu, Jan 21, 2016 at 2:32 PM, Nick Dimiduk 
>> wrote:
>>
>> > > TestDurability is failing in branch-1.1 with a small issue and have
>> just
>> > filed HBASE-15150 to fix it, JFYI.
>> >
>> > Thanks a lot Yu Li, I'll take a look.
>> >
>> > > I'm seeing that TestDurability failure as well, and am also finding
>> that
>> > TestWALLockup frequently times out and fails when running the unit test
>> > suite with 7u79.
>> >
>> > Thanks for checking guys. This release line has not had the diligent
>> > attention to test stability that later branches have. Indeed this point
>> was
>> > raised around earlier release from this branch as well. Previously we
>> were
>> > simply disabling flakey tests on this branch as bandwidth was not
>> available
>> > to fix them and they withheld release. I've depended more on CM testing
>> to
>> > verify bits and less on UT harness with far with branch-1.1. It is my
>> > intention to organize efforts around backporting test fixes (ie,
>> > from HBASE-14420), though I see no reason to withhold further patch
>> > releases in the mean time. This patch release is *months* over due.
>> >
>> > I am of course acting on the PMC's behalf as release manager. I will
>> defer
>> > to the PMC judgement on whether this UT situation constitutes acceptable
>> > parameters for release. I will absolutely accept community assistance in
>> > bring this branch's UT runs back into the green; it's not an effort I'm
>> > able to tackle solo in any timely manor.
>> >
>> > -n
>> >
>> > On Thu, Jan 21, 2016 at 11:36 AM, Andrew Purtell 
>> > wrote:
>> >
>> > > I'm seeing that TestDurability failure as well, and am also finding
>> that
>> > > TestWALLockup frequently times out and fails when running the unit
>> test
>> > > suite with 7u79.
>> > >
>> > > The LICENSE.txt file in the binary tarball has some unsubstituted
>> > > "${dep.licenses[0].comments}" for Apache Commons Collections and
>> Netty. I
>> > > think this is only a nit because right above where the substitutions
>> fail
>> > > we indicate in both cases the dependency is ASL 2.0 licensed and the
>> text
>> > > of that license appears elsewhere in the file.
>> > >
>> > > I'll defer to the RM if the above should sink the RC.
>> > >
>> > > Otherwise,
>> > > - Signatures and checksums look good
>> > > - Tarball structure looks good
>> > > - Build from source with release auditing enabled passes
>> > > - Ran LTT against a minicluster, loaded 1M rows (and updating 20%), no
>> > > errors, no unusual or unexpected messages in the logs, and reported
>> > > latencies are roughly as expected
>> > >
>> > > +1
>> > >
>> > >
>> > >
>> > > On Thu, Jan 21, 2016 at 5:23 AM, Yu Li  wrote:
>> > >
>> > > > Hi Nick,
>> > > >
>> > > > TestDurability is failing in branch-1.1 with a small issue and have
>> > just
>> > > > filed HBASE-15150 to fix it, JFYI.
>> > > >
>> > > > Best Regards,
>> > > > Yu
>> > > >
>> > > > On 21 January 2016 at 06:33, Enis Söztutar  wrote:
>> > > >
>> > > > > Thanks Nick for putting the RC together.
>> > > > >
>> > > > > Here is my +1.
>> > > > >
>> > > > > - checked crcs, sigs.
>> > > > >
>> > > > > - checked tarball layouts, files, jar files, etc.
>> > > > >
>> > > > > - checked the book in the bin tar
>> > > > >
>> > > > > - checked versions reported
>> > > > >
>> > > > > - checked the compat report
>> > > > >
>> > > > > - compiled with Hadoop 2.3 to 2.7
>> > > > >
>> > > > > - build with hbase-downstreamer
>> > > > >
>> > > > > - run local model, shell smoke tests, LTT.
>> > > > >
>> > > > > - Put it up on a 4 node cluster, ran LTT.
>> > > > >
>> > > > >
>> > > > > Everything looks nominal.
>> > > > >
>> > > >

[jira] [Created] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

2016-01-25 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-15169:


 Summary: Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is 
super duper flaky' to branch-1.1
 Key: HBASE-15169
 URL: https://issues.apache.org/jira/browse/HBASE-15169
 Project: HBase
  Issue Type: Sub-task
Reporter: Nick Dimiduk
Priority: Critical
 Fix For: 1.1.4


This one fails consistently for me and there's a fix hanging out upstream. 
Let's bring it back.



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

[jira] [Created] (HBASE-15170) Backport HBASE-14807 'TestWALLockup is flakey' to branch-1.1

2016-01-25 Thread Nick Dimiduk (JIRA) 
Nick Dimiduk created HBASE-15170:


 Summary: Backport HBASE-14807 'TestWALLockup is flakey' to 
branch-1.1
 Key: HBASE-15170
 URL: https://issues.apache.org/jira/browse/HBASE-15170
 Project: HBase
  Issue Type: Sub-task
  Components: test
Reporter: Nick Dimiduk
Priority: Critical


I'm hitting this one regularly and there's a fix for branch-1.2. Let's bring it 
back.



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

Successful: HBase Generate Website

2016-01-25 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. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git
  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/110/artifact/website.patch.zip
 | funzip > a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9.patch
  git fetch
  git checkout -b asf-site-a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9 
origin/asf-site
  git am a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9.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-a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9 branch, and you can review 
the differences by running:

  git diff origin/asf-site

There are lots of spurious changes, such as timestamps and CSS styles in 
tables. To see a list of files that have been added, deleted, renamed, changed 
type, or are otherwise interesting, use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 10 or more lines changed:

  git diff --stat origin/asf-site | grep -Ev "\|\s+\ [1-9]\ [\+-]+$"

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

  git push origin asf-site-a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9:asf-site

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

  git checkout asf-site && git branch -d 
asf-site-a87d9560fcf4803bdd7a01b6e4ec21435d4e11b9



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

[jira] [Created] (HBASE-15163) Add sampling code and metrics for get/scan/multi/mutate count separately

2016-01-25 Thread Yu Li (JIRA) 
Yu Li created HBASE-15163:
-

 Summary: Add sampling code and metrics for get/scan/multi/mutate 
count separately
 Key: HBASE-15163
 URL: https://issues.apache.org/jira/browse/HBASE-15163
 Project: HBase
  Issue Type: Sub-task
Reporter: Yu Li
Assignee: Yu Li


This way we could see QPS of different kinds of requests, to better analyze 
what's causing hot spot in system



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

Re: Trying to understand checkstyle with Yetus

2016-01-25 Thread Sean Busbey 
Hi Appy!

I'm copying in dev@yetus, since those folks are better positioned to answer
these questions.

The output for checkstyle is only present on that build because the patch
that it is testing only changed the hbase-server module. By default Yetus
only does correctness checks on modules that have been changed. Currently
the HBase personality maintains this behavior.

It might help explain the five files to arrange them in terms of the phases
Yetus Precommit uses when evaluating a patch[1] (I've skipped phases
unrelated to checkstyle):

- post-compile for branch (e.g. master, branch-1, branch-1.2, etc)

after checking out and installing everything, changed modules have
checkstyle run against the _current_ state of the repo

-- the checkstyle results go into branch-checkstyle-${module_name}.txt
-- the console output of running the checkstyle command (since hbase uses
maven) goes into maven-branch-checkstyle-${module_name}.txt

- post-compile for patch (i.e. after applying the changes to be tested)

-- the checkstyle results go into patch-checkstyle-${module_name}.txt
-- the console output of running the checkstyle command (since hbase uses
maven) goes into maven-branch-checkstyle-${module_name}.txt
-- the difference between the branch and patch versions of the checkstyle
output is calculated[2] and stored in diff-checkstyle-${module}.txt



Sounds like we (Yetus) should build some overview docs on plugins. Thanks
for the question!

[1]: http://yetus.apache.org/documentation/0.1.0/precommit-architecture/
[2]:
https://github.com/apache/yetus/blob/master/precommit/test-patch.d/checkstyle.sh#L65

On Sun, Jan 24, 2016 at 5:44 PM, Apekshit Sharma  wrote:

> So looking at artifacts of a build (
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/261/artifact/patchprocess/
> ),
> I see checkstyle for only 'hbase-server', why so? Is it that we haven't
> turned it on for other modules yet?
>
> Also I see following five different files, what is each one for?
>
> - branch-checkstyle-hbase-server.txt
> - diff-checkstyle-hbase-server.txt
> - maven-branch-checkstyle-hbase-server.txt
> - maven-patch-checkstyle-hbase-server.txt
> - patch-checkstyle-hbase-server.txt
>
>
> - Appy
>



-- 
Sean

[jira] [Created] (HBASE-15164) Fix broken links found via LinkLint

2016-01-25 Thread Misty Stanley-Jones (JIRA) 
Misty Stanley-Jones created HBASE-15164:
---

 Summary: Fix broken links found via LinkLint
 Key: HBASE-15164
 URL: https://issues.apache.org/jira/browse/HBASE-15164
 Project: HBase
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.0.0
Reporter: Misty Stanley-Jones
Assignee: Misty Stanley-Jones
 Fix For: 2.0.0


See 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/20/artifact/link_report/errorF.html.



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

[jira] [Resolved] (HBASE-7408) Make compaction to use pread instead of sequential read

2016-01-25 Thread stack (JIRA) 

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

stack resolved HBASE-7408.
--
Resolution: Unresolved

Resolving as 'unresolved'.

What is wrong here? Complaint is that sequential reads caused unwarranted i/o 
but don't we want the HDFS pipelining noted here HBASE-5979 when doing 
compactions?

> Make compaction to use pread instead of sequential read
> ---
>
> Key: HBASE-7408
> URL: https://issues.apache.org/jira/browse/HBASE-7408
> Project: HBase
>  Issue Type: Improvement
>Reporter: Rishit Shroff
>Assignee: Rishit Shroff
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> As we discovered lately, HFile compactions use sequential reads to fetch 
> blocks. It cause unwanted streaming of data from HDFS to region servers when 
> there is a cache hit. Lets change to use preads to reduce iops on disks.



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

[RESULT] [VOTE] The 1st HBase 0.98.17 release candidate (RC0) is available

2016-01-25 Thread Andrew Purtell 
With 6 +1 votes including my own, and no 0 or -1 votes, this vote has
passed and we have HBase 0.98.17. I will send the artifacts onward for
distribution and send out the release announcement shortly.

My thanks to all who voted!


On Sat, Jan 23, 2016 at 2:14 PM, Matteo Bertozzi 
wrote:

> +1
>
> - compiled from source and run few unit-test
> TestAdmin*,Test*Master*,Test*Region*
> - inspected the binary for hadoop1 and hadoop2
> - started hbase with both binaries
> - few commands from shell: create/disable/enable/drop/split, put/get/scan,
> snapshot/clone_snapshot
> - clicked around the webui
> - executed a simple bulkload and checked the data
> - performance evaluation run random write/read with autosplit
> - checked the logs for anything strange
>
> Matteo
>
>
> On Fri, Jan 22, 2016 at 2:51 AM, Ted Yu  wrote:
>
> > +1
> >
> > Ran test suite against hadoop 2.7.0 - passed
> > Exercised basic shell commands
> >
> > On Wed, Jan 20, 2016 at 9:51 PM,  wrote:
> >
> > > +1
> > >  - build from source- loaded 100m rows- executed some custom scan,
> load,
> > > and perf tests- nothing undue in the logs
> > >
> > > -- Lars
> > >
> > >   From: Andrew Purtell 
> > >  To: "dev@hbase.apache.org" 
> > >  Sent: Friday, January 15, 2016 11:24 PM
> > >  Subject: [VOTE] The 1st HBase 0.98.17 release candidate (RC0) is
> > available
> > >
> > > The 1st HBase 0.98.17 release candidate (RC0) is available for download
> > at
> > > https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.17RC0 and
> Maven
> > > artifacts are also available in the temporary repository
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1123/
> > .
> > >
> > > The detailed source and binary compatibility report for this release
> with
> > > respect to the previous is available for your review at ​
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/hbase-0.98.17RC0/0.98.16.1_0.98.17RC0_compat_report.html
> > > ​
> > > . There is one change of note to the RpcServer
> > > LimitedPrivate(COPROC,PHOENIX)/Evolving interface that I believe is
> > > acceptable and have confirmed does not impact downstream coprocessors
> who
> > > implement RPC schedulers like Apache Phoenix.
> > >
> > > The 55 issues resolved in this release can be found at
> > > http://s.apache.org/F4Q .
> > >
> > > I have made the following preliminary assessments of this candidate:
> > > - Build with source artifact with RAT and enforcers enabled (-Prelease)
> > > completes successfully
> > > - Unit test suite passes (7u79)
> > > - Loaded 1M rows with LTT, no errors or unexpected messages observed,
> all
> > > keys verified, latencies within expected range
> > > - Build and unit tests with head of Apache Phoenix 4.x-HBase-0.98
> branch
> > > passes (7u79)
> > >
> > > Signed with my new signing key 4B6D7DF3.
> > >
> > > ​Please try out the candidate and vote +1/0/-1. This vote will be open
> > for
> > > at least 72 hours. Unless objection I will try to close it Friday
> January
> > > 22, 2016 if we have sufficient votes. Three +1 votes from PMC will be
> > > required to release.​
> > >
> > > --
> > > Best regards,
> > >
> > >   - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> > >
> > >
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Second release candidate for HBase 1.1.3 (RC1) is available

2016-01-25 Thread Andrew Purtell 
Hi Nick,

Perhaps the silence in response to your inquiry and lack of vetos to date
can be interpreted as consensus to move forward. There are 2 +1 votes
already. If you decide to cast a third positive vote, we can release.


On Thu, Jan 21, 2016 at 2:32 PM, Nick Dimiduk  wrote:

> > TestDurability is failing in branch-1.1 with a small issue and have just
> filed HBASE-15150 to fix it, JFYI.
>
> Thanks a lot Yu Li, I'll take a look.
>
> > I'm seeing that TestDurability failure as well, and am also finding that
> TestWALLockup frequently times out and fails when running the unit test
> suite with 7u79.
>
> Thanks for checking guys. This release line has not had the diligent
> attention to test stability that later branches have. Indeed this point was
> raised around earlier release from this branch as well. Previously we were
> simply disabling flakey tests on this branch as bandwidth was not available
> to fix them and they withheld release. I've depended more on CM testing to
> verify bits and less on UT harness with far with branch-1.1. It is my
> intention to organize efforts around backporting test fixes (ie,
> from HBASE-14420), though I see no reason to withhold further patch
> releases in the mean time. This patch release is *months* over due.
>
> I am of course acting on the PMC's behalf as release manager. I will defer
> to the PMC judgement on whether this UT situation constitutes acceptable
> parameters for release. I will absolutely accept community assistance in
> bring this branch's UT runs back into the green; it's not an effort I'm
> able to tackle solo in any timely manor.
>
> -n
>
> On Thu, Jan 21, 2016 at 11:36 AM, Andrew Purtell 
> wrote:
>
> > I'm seeing that TestDurability failure as well, and am also finding that
> > TestWALLockup frequently times out and fails when running the unit test
> > suite with 7u79.
> >
> > The LICENSE.txt file in the binary tarball has some unsubstituted
> > "${dep.licenses[0].comments}" for Apache Commons Collections and Netty. I
> > think this is only a nit because right above where the substitutions fail
> > we indicate in both cases the dependency is ASL 2.0 licensed and the text
> > of that license appears elsewhere in the file.
> >
> > I'll defer to the RM if the above should sink the RC.
> >
> > Otherwise,
> > - Signatures and checksums look good
> > - Tarball structure looks good
> > - Build from source with release auditing enabled passes
> > - Ran LTT against a minicluster, loaded 1M rows (and updating 20%), no
> > errors, no unusual or unexpected messages in the logs, and reported
> > latencies are roughly as expected
> >
> > +1
> >
> >
> >
> > On Thu, Jan 21, 2016 at 5:23 AM, Yu Li  wrote:
> >
> > > Hi Nick,
> > >
> > > TestDurability is failing in branch-1.1 with a small issue and have
> just
> > > filed HBASE-15150 to fix it, JFYI.
> > >
> > > Best Regards,
> > > Yu
> > >
> > > On 21 January 2016 at 06:33, Enis Söztutar  wrote:
> > >
> > > > Thanks Nick for putting the RC together.
> > > >
> > > > Here is my +1.
> > > >
> > > > - checked crcs, sigs.
> > > >
> > > > - checked tarball layouts, files, jar files, etc.
> > > >
> > > > - checked the book in the bin tar
> > > >
> > > > - checked versions reported
> > > >
> > > > - checked the compat report
> > > >
> > > > - compiled with Hadoop 2.3 to 2.7
> > > >
> > > > - build with hbase-downstreamer
> > > >
> > > > - run local model, shell smoke tests, LTT.
> > > >
> > > > - Put it up on a 4 node cluster, ran LTT.
> > > >
> > > >
> > > > Everything looks nominal.
> > > >
> > > > Enis
> > > >
> > > > On Sat, Jan 16, 2016 at 8:06 PM, Nick Dimiduk 
> > > wrote:
> > > >
> > > > > After a short hiatus, I'm happy to announce the second release
> > > candidate
> > > > of
> > > > > HBase 1.1.3 (HBase-1.1.3RC1) is available for download at
> > > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.3RC1/
> > > > >
> > > > > Maven artifacts are also available in the staging repository
> > > > >
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1125/
> > > > >
> > > > > Artifacts are signed with my code signing subkey
> 0xAD9039071C3489BD,
> > > > > available in the Apache keys directory
> > > > > https://people.apache.org/keys/committer/ndimiduk.asc
> > > > >
> > > > > The detailed source and binary compatibility report vs 1.1.0 has
> been
> > > > > published for your review, at
> > > > > http://home.apache.org/~ndimiduk/1.1.0_1.1.3RC1_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 160 bug fixes since the
> 1.1.2
> > > > > release. Notable correctness fixes beyond RC0 include HBASE-14782,
> > > > > HBASE-14840, HBASE-14989, HBASE-14822, HBASE-15035, HBASE-15031,
>

Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Andrew Purtell 
I'll be adding tags under refs/rel/ for all previous HBase releases today,
using a snapshot of HBase's Apache git repository last updated at Monday
January 25 13:20:47 PST 2016.

-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Andrew Purtell 
Question: Would you like me to clean up afterward by pushing deletes for
the soon-to-be duplicate release tags? No rush on an answer. I'll wait a
few days for responses to come in.

On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell  wrote:

> I'll be adding tags under refs/rel/ for all previous HBase releases today,
> using a snapshot of HBase's Apache git repository last updated at Monday
> January 25 13:20:47 PST 2016.
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: [VOTE] Second release candidate for HBase 1.0.3 (RC1) is available. Please vote by Jan 26 2016

2016-01-25 Thread Enis Söztutar 
Here is the UT build for the RC:

https://builds.apache.org/view/H-L/view/HBase/job/HBase-1.0.3RC1/2/testReport/

All tests passed on the second run.

Enis

On Sat, Jan 23, 2016 at 8:00 PM, Enis Söztutar  wrote:

> Gently reminder for the vote.
>
> On Wed, Jan 20, 2016 at 2:40 PM, Enis Söztutar  wrote:
>
>> Here is my official +1. I executed the same tests from 1.1.3RC for
>> 1.0.3RC.
>>
>> - checked crcs, sigs.
>>
>> - checked tarball layouts, files, jar files, etc.
>>
>> - checked the book in the bin tar
>>
>> - checked versions reported
>>
>> - checked the compat report
>>
>> - compiled with Hadoop 2.2 to 2.7
>>
>> - build with hbase-downstreamer
>>
>> - run local model, shell smoke tests, LTT.
>>
>> - Put it up on a 4 node cluster, ran LTT.
>>
>>
>> Everything looks nominal.
>>
>> On Tue, Jan 19, 2016 at 8:29 PM, Enis Söztutar  wrote:
>>
>>> I am pleased to announce that the second release candidate for the
>>> release 1.0.3
>>> (HBase-1.0.3RC1), is available for download at
>>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.0.3RC1/
>>>
>>> Maven artifacts are also available in the temporary repository
>>> https://repository.apache.org/content/repositories/orgapachehbase-1126
>>>
>>> Signed with my code signing key E964B5FF. Can be found here:
>>> https://people.apache.org/keys/committer/enis.asc
>>>
>>> Signed tag in the repository can be found here:
>>> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=45baeb796eb98676b4b45f2d29ed1bd595e26cb7
>>>
>>> HBase 1.0.3 is the next “patch” release in the 1.0.x release line and
>>> supersedes all previous 1.0.x releases. According to the HBase’s semantic
>>> version guide (See [1]), the release candidate is source and binary
>>> compatible with 1.0.x for client applications and server side libraries
>>> (coprocessors, filters, etc).
>>>
>>> Please note that 1.0.3 is the last “scheduled” release in the 1.0.x line
>>> of releases since there is a limited amount of testing and release
>>> management bandwidth. Users are highly encouraged to upgrade to 1.1 line of
>>> releases if possible. However, if there is enough interest, or needed
>>> otherwise, we can still decide to do more releases. Please be encouraged to
>>> speak up if you want us to continue scheduled 1.0.x releases. See the
>>> hbase-dev mailing thread [6] for more information.
>>>
>>> Binary / source compatibility report of 1.0.3RC1 compared to 1.0.2 can
>>> be reached here:
>>> https://home.apache.org/~enis/1.0.2_1.0.3RC1_compat_report.html
>>>
>>> 1.0.3 release contains 102 fixes on top of 1.0.2 release. Most of
>>> the changes are
>>> bug fixes or test fixes except for the following:
>>>
>>> ** Sub-task
>>> * [HBASE-14221] - Reduce the number of time row comparison is done
>>> in a Scan
>>> * [HBASE-14535] - Integration test for rpc connection concurrency /
>>> deadlock testing·
>>> * [HBASE-14539] - Slight improvement of StoreScanner.optimize
>>> * [HBASE-14605] - Split fails due to 'No valid credentials' error
>>> when SecureBulkLoadEndpoint#start tries to access hdfs
>>> * [HBASE-14631] - Region merge request should be audited with
>>> request user through proper scope of doAs() calls to region observer
>>> notifications
>>> * [HBASE-14655] - Narrow the scope of doAs() calls to region
>>> observer notifications for compaction
>>> * [HBASE-14657] - Remove unneeded API from EncodedSeeker
>>> * [HBASE-14709] - Parent change breaks graceful_stop.sh on a cluster
>>> * [HBASE-15031] - Fix merge of MVCC and SequenceID performance
>>> regression in branch-1.0
>>> * [HBASE-15095] - isReturnResult=false  on fast path in branch-1.1
>>> and branch-1.0 is not respected
>>>
>>> ** Brainstorming
>>> * [HBASE-14869] - Better request latency and size histograms
>>>
>>> ** Improvement
>>> * [HBASE-14261] - Enhance Chaos Monkey framework by adding zookeeper
>>> and datanode fault injections.
>>> * [HBASE-14325] - Add snapshotinfo command to hbase script
>>> * [HBASE-14436] - HTableDescriptor#addCoprocessor will always make
>>> RegionCoprocessorHost create new Configuration
>>> * [HBASE-14582] - Regionserver status webpage bucketcache list can
>>> become huge
>>> * [HBASE-14586] - Use a maven profile to run Jacoco analysis
>>> * [HBASE-14643] - Avoid Splits from once again opening a closed
>>> reader for fetching the first and last key
>>>
>>> ** Task
>>> * [HBASE-14361] - ReplicationSink should create Connection instances
>>> lazily
>>>
>>>
>>> Full list of the issues can be found at
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12332968=Text=12310753=Create
>>>
>>> Compatibility
>>> -
>>> This release (1.0.3) is source, wire and binary compatible with all
>>> previous 1.0.x releases. Client applications do not have to be recompiled
>>> with the new version (unless new API is used) if upgrading from a previous
>>> 1.0.x. It is a drop-in

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Sean Busbey 
To date the only signing has been on release tags. AFAIK, signed tags are
only visible using "git show":

ex:

$ git show 1.0.0
tag 1.0.0
Tagger: Enis Soztutar 
Date:   Sat Feb 21 14:32:18 2015 -0800

Tag 1.0.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABCgAGBQJU6Qd4AAoJEAhFjDnpZLX/TvkP/2qrbuvm2Fp7ifrhZ5pngApl
plrI6yWUaXIS9cFj3fvInoXZ7CvKGSs6+ixngRsQBoYHvH1Lgu8SGcPVn5wj54WJ
bnwnhlvsfp3NQ1/UuADqCYPb8xRkHdijMnCxeRyZPGR3piZSCN8MwTSsdKbIJU8u
XCyDgFVx3IEOpphCDytZu5gZ6pRnvJfm3SqAjXC86/h8eTRvMwdbV1SwePWNA5HQ
CMHUBkLm4Nw8xD0Z7AdsKb+GxeM2P/xtN+ETQI0mOXJ9aWfsDQaGsMi4DXQRBGeT
h3Q/r6lImOjBqAnMeny3JLy3OIpDhFk7ezm2L7zwzaCgCGjWOcN/G7mmJkkl/i18
0MKKij7CPDP3yKfkhZs1HW68FalIaJ/kTQsRHIFOR+leVrB4xnaa2bx42lkWouqC
329qtubrGYN8jzqHSjoV5GvlAxz4tWdKz97N+WaBouzrQNkfAwkW9Kr/Cgr8XxQG
h+CxPJN8NEWdQKzEK6ibeGjCp8ULKfhuPUtIq3U/9vnFs4gtt0I6AQo5VeWxpePu
7BO1utwlWSQExMb5ES7fbwabh26yd9ZIfELpx7Ek3HR9jCEu7rE0pneKHUEFGR0d
+hXlYua9wcKmcftu4Q1nnz+tFFtCv9uosxWRMFHN/0RAw67rQ2D/hqS4vpnNsOQF
rjvbLk7ASDRbjD15WxXj
=ef23
-END PGP SIGNATURE-

commit 6c98bff7b719efdb16f71606f3b7d8229445eb81
Author: Enis Soztutar 
Date:   Sat Feb 14 19:41:51 2015 -0800

SNIP...

$  git show 1.1.2
tag 1.1.2
Tagger: Nick Dimiduk 
Date:   Tue Sep 1 09:15:22 2015 -0700

Tag 1.1.2
-BEGIN PGP SIGNATURE-

iQIcBAABCgAGBQJV5c8aAAoJEK2QOQccNIm9wjUQAIcZLsjYEKVohQJq5Wp3ZcrD
Z8dN265BIG1/IyBvvVYDEKQljWXeb5sIYxjoE0jVkiC80IWKmRKVgmR1K+lElPyR
Jx39ea+tNUKfrVj+vGN+3xOlLsc2RT+9x9EhKL+X38ZUUD7P0bSlcQvCekYFc0Ik
61VZDF24VXL4dvudahpOf+1mfQam9Ij4bEtwSe7tK8BSd1+FaPQKatEK5UqUAf+d
TTi3dnsoyZKOgiaSesZ6QbocBhB7h68ormnY9dowkCdr6CK/qXuNlCYNqtJx3EKQ
a0UsqbQNLimGANtO1llU8DiTbcS113z0SEiFyn4b/MuM8VtUQgMiLJx44o0ZhUB9
GDzXXMdMM7xkJjc7mUT5kxyqwsAo+G5MtaAS2gkMeeF4l5sZ+xT+DUKWfwfVBe0D
cg4JhhbX6/O4Nis92CQTbVLfgtF/K20cph5J7JiIf7wT+vkF2sIpb04INMCF/c+D
P5XGQt8UJ+Lewiln2E56UOOjRKZdj2JXBEOkiXXFledoXuGsBHWLUi0vL6FmmsZN
nd27SSsA/4cJerV4N91ekeqJ343oc6SYYuevfiTa6TIB2I9qRn7bLBFMedlzLSvt
0sKUgZvK3oDtOJ0N3gk+TkvXiHSBZQIpWw9H4hUXh+Vx5C+0FD+sGMSGea+md+b+
YHyDoviUo72QtexwuS5c
=I+Z4
-END PGP SIGNATURE-
...SNIP...

On Mon, Jan 25, 2016 at 5:22 PM, Andrew Purtell  wrote:

> I have made new refs in rel/ pointing to the same SHA as the earlier tag
> and pushed them.
>
> I don't believe any committers have or are planning to make PGP signed
> commits. I also made a quick check with 'git log' of recent release refs
> and did not find signed commits. That is a practice we could adopt. I'd be
> supportive of that. All committers would need to do so to make it
> worthwhile.
>
>
> On Mon, Jan 25, 2016 at 3:01 PM, Sean Busbey  wrote:
>
> > one question: will the new historic tags have your PGP signature rather
> > than the original RM(s)? If so, do we need to make a note of the cause of
> > this discrepancy?
> >
> > A vote in favor of leaving the old tags: since we've been treating
> release
> > tags as permalinks (regardless of their actual mutable state), folks are
> > likely to have links to them saved places.
> >
> > On Mon, Jan 25, 2016 at 3:26 PM, Andrew Purtell 
> > wrote:
> >
> > > Question: Would you like me to clean up afterward by pushing deletes
> for
> > > the soon-to-be duplicate release tags? No rush on an answer. I'll wait
> a
> > > few days for responses to come in.
> > >
> > > On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > I'll be adding tags under refs/rel/ for all previous HBase releases
> > > today,
> > > > using a snapshot of HBase's Apache git repository last updated at
> > Monday
> > > > January 25 13:20:47 PST 2016.
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >- Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Sean
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Sean

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Sean Busbey 
one question: will the new historic tags have your PGP signature rather
than the original RM(s)? If so, do we need to make a note of the cause of
this discrepancy?

A vote in favor of leaving the old tags: since we've been treating release
tags as permalinks (regardless of their actual mutable state), folks are
likely to have links to them saved places.

On Mon, Jan 25, 2016 at 3:26 PM, Andrew Purtell  wrote:

> Question: Would you like me to clean up afterward by pushing deletes for
> the soon-to-be duplicate release tags? No rush on an answer. I'll wait a
> few days for responses to come in.
>
> On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell 
> wrote:
>
> > I'll be adding tags under refs/rel/ for all previous HBase releases
> today,
> > using a snapshot of HBase's Apache git repository last updated at Monday
> > January 25 13:20:47 PST 2016.
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Best regards,
>
>- Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>



-- 
Sean

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Andrew Purtell 
I have made new refs in rel/ pointing to the same SHA as the earlier tag
and pushed them.

I don't believe any committers have or are planning to make PGP signed
commits. I also made a quick check with 'git log' of recent release refs
and did not find signed commits. That is a practice we could adopt. I'd be
supportive of that. All committers would need to do so to make it
worthwhile.


On Mon, Jan 25, 2016 at 3:01 PM, Sean Busbey  wrote:

> one question: will the new historic tags have your PGP signature rather
> than the original RM(s)? If so, do we need to make a note of the cause of
> this discrepancy?
>
> A vote in favor of leaving the old tags: since we've been treating release
> tags as permalinks (regardless of their actual mutable state), folks are
> likely to have links to them saved places.
>
> On Mon, Jan 25, 2016 at 3:26 PM, Andrew Purtell 
> wrote:
>
> > Question: Would you like me to clean up afterward by pushing deletes for
> > the soon-to-be duplicate release tags? No rush on an answer. I'll wait a
> > few days for responses to come in.
> >
> > On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell 
> > wrote:
> >
> > > I'll be adding tags under refs/rel/ for all previous HBase releases
> > today,
> > > using a snapshot of HBase's Apache git repository last updated at
> Monday
> > > January 25 13:20:47 PST 2016.
> > >
> > > --
> > > Best regards,
> > >
> > >- Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Sean
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Adding rel/ tags for previous HBase releases today

2016-01-25 Thread Andrew Purtell 
I see.

The release tags I pushed are not signed.

On Mon, Jan 25, 2016 at 3:30 PM, Sean Busbey  wrote:

> To date the only signing has been on release tags. AFAIK, signed tags are
> only visible using "git show":
>
> ex:
>
> $ git show 1.0.0
> tag 1.0.0
> Tagger: Enis Soztutar 
> Date:   Sat Feb 21 14:32:18 2015 -0800
>
> Tag 1.0.0
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABCgAGBQJU6Qd4AAoJEAhFjDnpZLX/TvkP/2qrbuvm2Fp7ifrhZ5pngApl
> plrI6yWUaXIS9cFj3fvInoXZ7CvKGSs6+ixngRsQBoYHvH1Lgu8SGcPVn5wj54WJ
> bnwnhlvsfp3NQ1/UuADqCYPb8xRkHdijMnCxeRyZPGR3piZSCN8MwTSsdKbIJU8u
> XCyDgFVx3IEOpphCDytZu5gZ6pRnvJfm3SqAjXC86/h8eTRvMwdbV1SwePWNA5HQ
> CMHUBkLm4Nw8xD0Z7AdsKb+GxeM2P/xtN+ETQI0mOXJ9aWfsDQaGsMi4DXQRBGeT
> h3Q/r6lImOjBqAnMeny3JLy3OIpDhFk7ezm2L7zwzaCgCGjWOcN/G7mmJkkl/i18
> 0MKKij7CPDP3yKfkhZs1HW68FalIaJ/kTQsRHIFOR+leVrB4xnaa2bx42lkWouqC
> 329qtubrGYN8jzqHSjoV5GvlAxz4tWdKz97N+WaBouzrQNkfAwkW9Kr/Cgr8XxQG
> h+CxPJN8NEWdQKzEK6ibeGjCp8ULKfhuPUtIq3U/9vnFs4gtt0I6AQo5VeWxpePu
> 7BO1utwlWSQExMb5ES7fbwabh26yd9ZIfELpx7Ek3HR9jCEu7rE0pneKHUEFGR0d
> +hXlYua9wcKmcftu4Q1nnz+tFFtCv9uosxWRMFHN/0RAw67rQ2D/hqS4vpnNsOQF
> rjvbLk7ASDRbjD15WxXj
> =ef23
> -END PGP SIGNATURE-
>
> commit 6c98bff7b719efdb16f71606f3b7d8229445eb81
> Author: Enis Soztutar 
> Date:   Sat Feb 14 19:41:51 2015 -0800
>
> SNIP...
>
> $  git show 1.1.2
> tag 1.1.2
> Tagger: Nick Dimiduk 
> Date:   Tue Sep 1 09:15:22 2015 -0700
>
> Tag 1.1.2
> -BEGIN PGP SIGNATURE-
>
> iQIcBAABCgAGBQJV5c8aAAoJEK2QOQccNIm9wjUQAIcZLsjYEKVohQJq5Wp3ZcrD
> Z8dN265BIG1/IyBvvVYDEKQljWXeb5sIYxjoE0jVkiC80IWKmRKVgmR1K+lElPyR
> Jx39ea+tNUKfrVj+vGN+3xOlLsc2RT+9x9EhKL+X38ZUUD7P0bSlcQvCekYFc0Ik
> 61VZDF24VXL4dvudahpOf+1mfQam9Ij4bEtwSe7tK8BSd1+FaPQKatEK5UqUAf+d
> TTi3dnsoyZKOgiaSesZ6QbocBhB7h68ormnY9dowkCdr6CK/qXuNlCYNqtJx3EKQ
> a0UsqbQNLimGANtO1llU8DiTbcS113z0SEiFyn4b/MuM8VtUQgMiLJx44o0ZhUB9
> GDzXXMdMM7xkJjc7mUT5kxyqwsAo+G5MtaAS2gkMeeF4l5sZ+xT+DUKWfwfVBe0D
> cg4JhhbX6/O4Nis92CQTbVLfgtF/K20cph5J7JiIf7wT+vkF2sIpb04INMCF/c+D
> P5XGQt8UJ+Lewiln2E56UOOjRKZdj2JXBEOkiXXFledoXuGsBHWLUi0vL6FmmsZN
> nd27SSsA/4cJerV4N91ekeqJ343oc6SYYuevfiTa6TIB2I9qRn7bLBFMedlzLSvt
> 0sKUgZvK3oDtOJ0N3gk+TkvXiHSBZQIpWw9H4hUXh+Vx5C+0FD+sGMSGea+md+b+
> YHyDoviUo72QtexwuS5c
> =I+Z4
> -END PGP SIGNATURE-
> ...SNIP...
>
> On Mon, Jan 25, 2016 at 5:22 PM, Andrew Purtell 
> wrote:
>
> > I have made new refs in rel/ pointing to the same SHA as the earlier tag
> > and pushed them.
> >
> > I don't believe any committers have or are planning to make PGP signed
> > commits. I also made a quick check with 'git log' of recent release refs
> > and did not find signed commits. That is a practice we could adopt. I'd
> be
> > supportive of that. All committers would need to do so to make it
> > worthwhile.
> >
> >
> > On Mon, Jan 25, 2016 at 3:01 PM, Sean Busbey 
> wrote:
> >
> > > one question: will the new historic tags have your PGP signature rather
> > > than the original RM(s)? If so, do we need to make a note of the cause
> of
> > > this discrepancy?
> > >
> > > A vote in favor of leaving the old tags: since we've been treating
> > release
> > > tags as permalinks (regardless of their actual mutable state), folks
> are
> > > likely to have links to them saved places.
> > >
> > > On Mon, Jan 25, 2016 at 3:26 PM, Andrew Purtell 
> > > wrote:
> > >
> > > > Question: Would you like me to clean up afterward by pushing deletes
> > for
> > > > the soon-to-be duplicate release tags? No rush on an answer. I'll
> wait
> > a
> > > > few days for responses to come in.
> > > >
> > > > On Mon, Jan 25, 2016 at 1:24 PM, Andrew Purtell  >
> > > > wrote:
> > > >
> > > > > I'll be adding tags under refs/rel/ for all previous HBase releases
> > > > today,
> > > > > using a snapshot of HBase's Apache git repository last updated at
> > > Monday
> > > > > January 25 13:20:47 PST 2016.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >
> > > > >- Andy
> > > > >
> > > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > > Hein
> > > > > (via Tom White)
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >- Andy
> > > >
> > > > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein
> > > > (via Tom White)
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >- Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
> --
> Sean
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

[jira] [Created] (HBASE-15165) AsyncProcess can spin wait indefinitly

2016-01-25 Thread Elliott Clark (JIRA) 
Elliott Clark created HBASE-15165:
-

 Summary: AsyncProcess can spin wait indefinitly
 Key: HBASE-15165
 URL: https://issues.apache.org/jira/browse/HBASE-15165
 Project: HBase
  Issue Type: Bug
Reporter: Elliott Clark


When the max outstanding requests per region or per server is reached, all 
threads trying to send more requests to that server will spin and will spin 
forever with no sleep, and no regard for timeouts.



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

[jira] [Created] (HBASE-15161) Umbrella: Miscellaneous improvements from production usage

2016-01-25 Thread Yu Li (JIRA) 
Yu Li created HBASE-15161:
-

 Summary: Umbrella: Miscellaneous improvements from production usage
 Key: HBASE-15161
 URL: https://issues.apache.org/jira/browse/HBASE-15161
 Project: HBase
  Issue Type: Umbrella
Reporter: Yu Li
Assignee: Yu Li


We use HBase to (mainly) build index for our search engine in Alibaba. Recently 
we are upgrading our online cluster from 0.98.12 to 1.x and I'd like to take 
the opportunity to contribute a bunch of our private patches to community 
(better late than never, I hope :-)). This is an umbrella to track this effort.



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

[jira] [Created] (HBASE-15162) Add separate metrics for meta/data block hit ratio in cache

2016-01-25 Thread Yu Li (JIRA) 
Yu Li created HBASE-15162:
-

 Summary: Add separate metrics for meta/data block hit ratio in 
cache
 Key: HBASE-15162
 URL: https://issues.apache.org/jira/browse/HBASE-15162
 Project: HBase
  Issue Type: Improvement
Reporter: Yu Li
Assignee: Yu Li


Currently we already have a metrics in name of {{blockCacheExpressHitPercent}} 
to indicate the cache hit ratio. However, since meta block is small and often 
cached in memory with a high hit ratio, this "mixed" metrics could not show the 
real data block hit ratio which is more concerned.

We propose to add two new metrics to show meta and data block cache hit ratio 
separately, while reserving the old metrics for backward compatibility.



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

Successful: hbase.apache.org HTML Checker

2016-01-25 Thread Apache Jenkins Server 
Successful

If successful, the HTML and link-checking report for http://hbase.apache.org is 
available at 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/20/artifact/link_report/index.html.

If failed, see 
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/20/console.

Re: [VOTE] Second release candidate for HBase 1.1.3 (RC1) is available

2016-01-25 Thread Nick Dimiduk 
Yes Andrew, that's my conclusion as well. I will evaluate the bits for
myself this evening. I'll also dig into the test results from my weekend
runs.

On Monday, January 25, 2016, Andrew Purtell  wrote:

> Hi Nick,
>
> Perhaps the silence in response to your inquiry and lack of vetos to date
> can be interpreted as consensus to move forward. There are 2 +1 votes
> already. If you decide to cast a third positive vote, we can release.
>
>
> On Thu, Jan 21, 2016 at 2:32 PM, Nick Dimiduk  > wrote:
>
> > > TestDurability is failing in branch-1.1 with a small issue and have
> just
> > filed HBASE-15150 to fix it, JFYI.
> >
> > Thanks a lot Yu Li, I'll take a look.
> >
> > > I'm seeing that TestDurability failure as well, and am also finding
> that
> > TestWALLockup frequently times out and fails when running the unit test
> > suite with 7u79.
> >
> > Thanks for checking guys. This release line has not had the diligent
> > attention to test stability that later branches have. Indeed this point
> was
> > raised around earlier release from this branch as well. Previously we
> were
> > simply disabling flakey tests on this branch as bandwidth was not
> available
> > to fix them and they withheld release. I've depended more on CM testing
> to
> > verify bits and less on UT harness with far with branch-1.1. It is my
> > intention to organize efforts around backporting test fixes (ie,
> > from HBASE-14420), though I see no reason to withhold further patch
> > releases in the mean time. This patch release is *months* over due.
> >
> > I am of course acting on the PMC's behalf as release manager. I will
> defer
> > to the PMC judgement on whether this UT situation constitutes acceptable
> > parameters for release. I will absolutely accept community assistance in
> > bring this branch's UT runs back into the green; it's not an effort I'm
> > able to tackle solo in any timely manor.
> >
> > -n
> >
> > On Thu, Jan 21, 2016 at 11:36 AM, Andrew Purtell  >
> > wrote:
> >
> > > I'm seeing that TestDurability failure as well, and am also finding
> that
> > > TestWALLockup frequently times out and fails when running the unit test
> > > suite with 7u79.
> > >
> > > The LICENSE.txt file in the binary tarball has some unsubstituted
> > > "${dep.licenses[0].comments}" for Apache Commons Collections and
> Netty. I
> > > think this is only a nit because right above where the substitutions
> fail
> > > we indicate in both cases the dependency is ASL 2.0 licensed and the
> text
> > > of that license appears elsewhere in the file.
> > >
> > > I'll defer to the RM if the above should sink the RC.
> > >
> > > Otherwise,
> > > - Signatures and checksums look good
> > > - Tarball structure looks good
> > > - Build from source with release auditing enabled passes
> > > - Ran LTT against a minicluster, loaded 1M rows (and updating 20%), no
> > > errors, no unusual or unexpected messages in the logs, and reported
> > > latencies are roughly as expected
> > >
> > > +1
> > >
> > >
> > >
> > > On Thu, Jan 21, 2016 at 5:23 AM, Yu Li  > wrote:
> > >
> > > > Hi Nick,
> > > >
> > > > TestDurability is failing in branch-1.1 with a small issue and have
> > just
> > > > filed HBASE-15150 to fix it, JFYI.
> > > >
> > > > Best Regards,
> > > > Yu
> > > >
> > > > On 21 January 2016 at 06:33, Enis Söztutar  > wrote:
> > > >
> > > > > Thanks Nick for putting the RC together.
> > > > >
> > > > > Here is my +1.
> > > > >
> > > > > - checked crcs, sigs.
> > > > >
> > > > > - checked tarball layouts, files, jar files, etc.
> > > > >
> > > > > - checked the book in the bin tar
> > > > >
> > > > > - checked versions reported
> > > > >
> > > > > - checked the compat report
> > > > >
> > > > > - compiled with Hadoop 2.3 to 2.7
> > > > >
> > > > > - build with hbase-downstreamer
> > > > >
> > > > > - run local model, shell smoke tests, LTT.
> > > > >
> > > > > - Put it up on a 4 node cluster, ran LTT.
> > > > >
> > > > >
> > > > > Everything looks nominal.
> > > > >
> > > > > Enis
> > > > >
> > > > > On Sat, Jan 16, 2016 at 8:06 PM, Nick Dimiduk  >
> > > > wrote:
> > > > >
> > > > > > After a short hiatus, I'm happy to announce the second release
> > > > candidate
> > > > > of
> > > > > > HBase 1.1.3 (HBase-1.1.3RC1) is available for download at
> > > > > > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.3RC1/
> > > > > >
> > > > > > Maven artifacts are also available in the staging repository
> > > > > >
> > > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1125/
> > > > > >
> > > > > > Artifacts are signed with my code signing subkey
> > 0xAD9039071C3489BD,
> > > > > > available in the Apache keys directory
> > > > > > https://people.apache.org/keys/committer/ndimiduk.asc
> > > > > >
> > > > > > The detailed source and binary compatibility