Re: [VOTE] First release candidate for HBase 1.1.9 (RC0) is available
+1 - verified tarballs vs public key on people.apache.org. - extracted bin tgz: - inspect structure. look good. - with jdk1.8.0_65: - run LoadTestTool against standalone bin tgz with FAST_DIFF block encoder and ROWCOL blooms. No issues, logs look good. - poked around webUI. looks good. - load the site, browsed book. - extracted src 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. - ran the hbase-downstreamer project vs. the staged maven repository. tests pass. On Mon, Feb 20, 2017 at 11:44 PM, Nick Dimiduk wrote: > I'm happy to announce the first release candidate of HBase 1.1.9 (HBase- > 1.1.9RC0) is available for download at https://dist.apache.org/ > repos/dist/dev/hbase/hbase-1.1.9RC0/ > > Maven artifacts are also available in the staging repository > https://repository.apache.org/content/repositories/orgapachehbase-1163 > > Artifacts are signed with my code signing subkey 0xAD9039071C3489BD, > available in the Apache keys directory https://people.apach > e.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=commit;h= > 0d1feabed5295495ed2257d31fab9e6553e8a9d7 > > The detailed source and binary compatibility report vs 1.1.8 has been > published for your review, at http://home.apache.org/~ > ndimiduk/1.1.8_1.1.9RC0_compat_report.html > > HBase 1.1.9 is the ninth 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 nearly 20 bug fixes since the 1.1 > .8 release. Notable correctness fixes include HBASE-17238, > HBASE-17587, HBASE-17275, and HBASE-17265. > > The full list of fixes included in this release is available at > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12310753&version=12338734 and in the CHANGES.txt file included > in the distribution. > > Please try out this candidate and vote +/-1 by 23:59 Pacific time on > Sunday, 2017-02-26 as to whether we should release these artifacts as > HBase 1.1.9. > > Thanks, > Nick >
[VOTE] First release candidate for HBase 1.1.9 (RC0) is available
I'm happy to announce the first release candidate of HBase 1.1.9 (HBase-1.1. 9RC0) is available for download at https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.9RC0/ Maven artifacts are also available in the staging repository https://repository.apache.org/content/repositories/orgapachehbase-1163 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=commit;h=0d1feabed5295495ed2257d31fab9e6553e8a9d7 The detailed source and binary compatibility report vs 1.1.8 has been published for your review, at http://home.apache.org/~ndimiduk/1.1.8_1.1.9RC0_compat_report.html HBase 1.1.9 is the ninth 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 nearly 20 bug fixes since the 1.1.8 release. Notable correctness fixes include HBASE-17238, HBASE-17587, HBASE-17275, and HBASE-17265. The full list of fixes included in this release is available at https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753&version=12338734 and in the CHANGES.txt file included in the distribution. Please try out this candidate and vote +/-1 by 23:59 Pacific time on Sunday, 2017-02-26 as to whether we should release these artifacts as HBase 1.1.9. Thanks, Nick
[jira] [Created] (HBASE-17673) Monitored RPC Handler not show in the WebUI
Allan Yang created HBASE-17673:
--
Summary: Monitored RPC Handler not show in the WebUI
Key: HBASE-17673
URL: https://issues.apache.org/jira/browse/HBASE-17673
Project: HBase
Issue Type: Bug
Affects Versions: 1.1.8, 1.2.4, 2.0.0, 3.0.0
Reporter: Allan Yang
Assignee: Allan Yang
Priority: Minor
This issue has been fixed once in HBASE-14674. But, I noticed that almost all
RS in our production environment still have this problem. Strange thing is that
newly started servers seems do not affected. Digging for a while, then I
realize the {{CircularFifoBuffer}} introduced by HBASE-10312 is the root cause.
The RPC hander's monitoredTask only create once, if the server is flooded with
tasks, RPC monitoredTask can be purged by CircularFifoBuffer, and then never
visible in WebUI.
So my solution is create a list for RPC monitoredTask sepreately. It is OK to
do so since the RPC handlers remain in a fixed number. It won't increase or
decrease during the lifetime of the server.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17672) "Grant should set access rights appropriately" test fails
Ted Yu created HBASE-17672:
--
Summary: "Grant should set access rights appropriately" test fails
Key: HBASE-17672
URL: https://issues.apache.org/jira/browse/HBASE-17672
Project: HBase
Issue Type: Test
Reporter: Ted Yu
The following test failure is reproducible after HBASE-17472 went in:
{code}
1) Failure:
test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
[./src/test/ruby/hbase/security_admin_test.rb:66:in
`test_Grant_should_set_access_rights_appropriately'
/Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in
`user_permission'
file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
`each'
/Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in
`user_permission'
./src/test/ruby/hbase/security_admin_test.rb:65:in
`test_Grant_should_set_access_rights_appropriately'
org/jruby/RubyProc.java:270:in `call'
org/jruby/RubyKernel.java:2105:in `send'
org/jruby/RubyArray.java:1620:in `each'
org/jruby/RubyArray.java:1620:in `each']:
{code}
[~openinx]:
Can you take a look ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (HBASE-17671) HBase Thrift2 OutOfMemory
Bingbing Wang created HBASE-17671: - Summary: HBase Thrift2 OutOfMemory Key: HBASE-17671 URL: https://issues.apache.org/jira/browse/HBASE-17671 Project: HBase Issue Type: Bug Components: Thrift Affects Versions: 0.98.6 Environment: Product Reporter: Bingbing Wang Priority: Critical We have a HBase Thrift2 server deployed on Windows, basically the physical view looks like: QueryEngine <==> HBase Thrift2 <==> HBase cluster Here QueryEngine is a C++ application, and HBase cluster is a about 50-nodes HBase cluster (CDH 5.3.3, namely Hbase version 0.98.6). Our Thrift2 Java options looks like: -server -Xms4096m -Xmx4096m -XX:MaxDirectMemorySize=8192m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:G1HeapRegionSize=4M -XX:InitiatingHeapOccupancyPercent=40 -XX:+PrintAdaptiveSizePolicy -XX:+PrintPromotionFailure -Dhbase.log.dir=d:\vhayu\thrift2\log -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:PrintFLSStatistics=1 -Xloggc:log_gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=200M -Dhbase.log.file=hbase-thrift2.log -Dhbase.home.dir=D:\vhayu\thrift2\hbase0.98 -Dhbase.id.str=root -Dlog4j.info -Dhbase.root.logger=INFO,DRFA -cp "d:\vhayu\thrift2\hbase0.98\*;d:\vhayu\thrift2\conf" org.apache.hadoop.hbase.thrift2.ThriftServer -b 127.0.0.1 -f framed start The phenomenon of the issue is that after some time running, Thrift2 sometimes reports OOM and heap dump file (.hprof) file was generated. The consequence of this will always trigger high latency form HBase cluster. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
Successful: hbase.apache.org HTML Checker
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/83/artifact/link_report/index.html. If failed, see https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/83/console.
Successful: HBase Generate Website
Build status: Successful
If successful, the website and docs have been generated. To update the live
site, follow the instructions below. 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/494/artifact/website.patch.zip
| funzip > 22fa1cd3df3ed16ddbc0336ac2e52964c1e22665.patch
git fetch
git checkout -b asf-site-22fa1cd3df3ed16ddbc0336ac2e52964c1e22665
origin/asf-site
git am --whitespace=fix 22fa1cd3df3ed16ddbc0336ac2e52964c1e22665.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-22fa1cd3df3ed16ddbc0336ac2e52964c1e22665 branch.
There are lots of spurious changes, such as timestamps and CSS styles in
tables, so a generic git diff is not very useful. 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 100 or more lines changed:
git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'
When you are satisfied, publish your changes to origin/asf-site using these
commands:
git commit --allow-empty -m "Empty commit" # to work around a current ASF
INFRA bug
git push origin asf-site-22fa1cd3df3ed16ddbc0336ac2e52964c1e22665:asf-site
git checkout asf-site
git branch -D asf-site-22fa1cd3df3ed16ddbc0336ac2e52964c1e22665
Changes take a couple of minutes to be propagated. You can verify whether they
have been propagated by looking at the Last Published date at the bottom of
http://hbase.apache.org/. It should match the date in the index.html on the
asf-site branch in Git.
As a courtesy- reply-all to this email to let other committers know you pushed
the site.
If failed, see https://builds.apache.org/job/hbase_generate_website/494/console
[jira] [Resolved] (HBASE-17670) LruBlockCache with VictimHandler should evict from bucket cache also when eviction by filename happens
[ https://issues.apache.org/jira/browse/HBASE-17670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan resolved HBASE-17670. Resolution: Not A Problem Sorry just saw that the code already does it. > LruBlockCache with VictimHandler should evict from bucket cache also when > eviction by filename happens > -- > > Key: HBASE-17670 > URL: https://issues.apache.org/jira/browse/HBASE-17670 > Project: HBase > Issue Type: Bug > Components: BlockCache, BucketCache >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Minor > Fix For: 2.0.0 > > > When VictimHandler is used we use the bucket cache to cache those blocks that > are evicted. So in case of where we close the hfile and call > evictBlocksByHfileName - I think it still makes sense to call evict on the > vicitmHandler also. Else the victimHandler is going to just occupy the space > till the eviction thread in that vicitm handler clears it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17670) LruBlockCache with VictimHandler should evict from bucket cache also when eviction by filename happens
ramkrishna.s.vasudevan created HBASE-17670: -- Summary: LruBlockCache with VictimHandler should evict from bucket cache also when eviction by filename happens Key: HBASE-17670 URL: https://issues.apache.org/jira/browse/HBASE-17670 Project: HBase Issue Type: Bug Components: BlockCache, BucketCache Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Priority: Minor Fix For: 2.0.0 When VictimHandler is used we use the bucket cache to cache those blocks that are evicted. So in case of where we close the hfile and call evictBlocksByHfileName - I think it still makes sense to call evict on the vicitmHandler also. Else the victimHandler is going to just occupy the space till the eviction thread in that vicitm handler clears it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17669) Implement async mergeRegion/splitRegion methods.
Zheng Hu created HBASE-17669: Summary: Implement async mergeRegion/splitRegion methods. Key: HBASE-17669 URL: https://issues.apache.org/jira/browse/HBASE-17669 Project: HBase Issue Type: Sub-task Components: Admin, asyncclient, Client Affects Versions: 2.0.0 Reporter: Zheng Hu Assignee: Zheng Hu Fix For: 2.0.0 RT -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17668) Implement async assgin/offline/move/unassign methods
Zheng Hu created HBASE-17668: Summary: Implement async assgin/offline/move/unassign methods Key: HBASE-17668 URL: https://issues.apache.org/jira/browse/HBASE-17668 Project: HBase Issue Type: Sub-task Components: Admin, asyncclient, Client Affects Versions: 2.0.0 Reporter: Zheng Hu Assignee: Zheng Hu Fix For: 2.0.0 Implement following methods for async admin client: 1. assign region; 2. unassign region; 3. offline region; 4. move regioin; -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (HBASE-17667) Implement async flush/compact region methods
Zheng Hu created HBASE-17667:
Summary: Implement async flush/compact region methods
Key: HBASE-17667
URL: https://issues.apache.org/jira/browse/HBASE-17667
Project: HBase
Issue Type: Sub-task
Components: Admin, asyncclient, Client
Affects Versions: 2.0.0
Reporter: Zheng Hu
Assignee: Zheng Hu
Fix For: 2.0.0
Implement following methods for async admin:
{code}
1. flush table ;
2. flush region;
3. compact table;
4. compact region;
5. compact region server;
6. major compact for table;
7. major compact for region;
8. major compact for CF;
9. major compact for specific region and specific CF;
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
