[jira] [Created] (HBASE-15784) MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor
Jingcheng Du created HBASE-15784: Summary: MIsuse core/maxPoolSize of LinkedBlockingQueue in ThreadPoolExecutor Key: HBASE-15784 URL: https://issues.apache.org/jira/browse/HBASE-15784 Project: HBase Issue Type: Bug Components: Client, Replication, Thrift Reporter: Jingcheng Du Assignee: Jingcheng Du LinkedBlockingQueue is usually used in ThreadPoolExecutor. It allows the thread pool not to be blocked if the number of running threads in the pool is less than the max pool size and the queue is not full. But when the core pool size of ThreadPoolExecutor is different from the max pool size, the things don't go as expected. When the number of running threads is the same with the core size, more requests of executions are added into the LinkedBlockingQueue. And the requests can be executed again only when LinkedBlockingQueue is full or some of running threads are finished. Thus it is better to use the same value for the core and max pool size when the LinkedBlockingQueue is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15783) AccessControlConstants#OP_ATTRIBUTE_ACL_STRATEGY_CELL_FIRST not used any more.
ramkrishna.s.vasudevan created HBASE-15783: -- Summary: AccessControlConstants#OP_ATTRIBUTE_ACL_STRATEGY_CELL_FIRST not used any more. Key: HBASE-15783 URL: https://issues.apache.org/jira/browse/HBASE-15783 Project: HBase Issue Type: Bug Reporter: ramkrishna.s.vasudevan Assignee: ramkrishna.s.vasudevan Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0 This is based on a mail in the user list. OP_ATTRIBUTE_ACL_STRATEGY_CELL_FIRST in AccessControlConstants is not used any more in the code and AccessControlconstants is Public. We need to either bring in this feature or remove the constant from the Public APi which may be misleading. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Make AsyncFSWAL the default WAL in 2.0
On Thu, May 5, 2016 at 7:39 PM, Yu Li wrote: > Almost miss the party... > > bq. Do you think it worth to backport this feature to branch-1 and release > it in the next 1.x release? This may introduce a compatibility issue as > said > in HBASE-14949 that we need HBASE-14949 to make sure that the rolling > upgrade > does not lose data... > From current perf data I think the effort is worthwhile, we already started > some work here and will run it on production after some carefully testing > (and of course, if the perf number confirmed, but I'm optimistic somehow > :-P). Regarding HBASE-14949, I guess a two-step rolling upgrade will make > it work, right? (And I guess this will also be a question when we upgrade > from 1.x to 2.0 later?) > > Or a clean shutdown and restart? Or a fresh install? I'd think backport would be fine if you have to enable it and it has warnings and is clear on circumstances under which there could be dataloss. St.Ack > btw, I'm +1 about making asyncfswal as default in 2.0 :-) > > Best Regards, > Yu > > On 6 May 2016 at 09:49, Ted Yu wrote: > > > Thanks for your effort, Duo. > > > > I am in favor of turning AsyncWAL as default in master branch. > > > > Cheers > > > > On Thu, May 5, 2016 at 6:03 PM, 张铎 wrote: > > > > > Some progress. > > > > > > I have filed HBASE-15743 for the transparent encryption support, > > > and HBASE-15754 for the AES encryption UT. Now both of them are > resolved. > > > Let's resume the discussion here. > > > > > > Thanks. > > > > > > 2016-05-03 10:09 GMT+08:00 张铎 : > > > > > > > Fine, will add the testcase. > > > > > > > > And for the RPC, we only implement a new client side DTP here and > still > > > > use the original RPC. > > > > > > > > Thanks. > > > > > > > > 2016-05-03 3:20 GMT+08:00 Gary Helmling : > > > > > > > >> On Fri, Apr 29, 2016 at 6:24 PM 张铎 wrote: > > > >> > > > >> > Yes, it does. There is testcase that enumerates all the possible > > > >> protection > > > >> > level(authentication, integrity and privacy) and encryption > > > >> algorithm(none, > > > >> > 3des, rc4). > > > >> > > > > >> > > > > >> > > > > >> > > > > > > https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/io/asyncfs/TestSaslFanOutOneBlockAsyncDFSOutput.java > > > >> > > > > >> > I have also tested it in a secure cluster(hbase-2.0.0-SNAPSHOT and > > > >> > hadoop-2.4.0). > > > >> > > > > >> > > > >> Thanks. Can you add in support for testing with AES > > > >> (dfs.encrypt.data.transfer.cipher.suites=AES/CTR/NoPadding)? This > is > > > only > > > >> available in Hadoop 2.6.0+, but I think is far more likely to be > used > > in > > > >> production than 3des or rc4. > > > > > > > > > > > >> Also, have you been following HADOOP-10768? That is changing Hadoop > > RPC > > > >> encryption negotiation to support more performant AES wrapping, > > similar > > > to > > > >> what is now supported in the data transfer pipeline. > > > >> > > > > > > > > > > > > > >
Re: [DISCUSS] Make AsyncFSWAL the default WAL in 2.0
Almost miss the party... bq. Do you think it worth to backport this feature to branch-1 and release it in the next 1.x release? This may introduce a compatibility issue as said in HBASE-14949 that we need HBASE-14949 to make sure that the rolling upgrade does not lose data... >From current perf data I think the effort is worthwhile, we already started some work here and will run it on production after some carefully testing (and of course, if the perf number confirmed, but I'm optimistic somehow :-P). Regarding HBASE-14949, I guess a two-step rolling upgrade will make it work, right? (And I guess this will also be a question when we upgrade from 1.x to 2.0 later?) btw, I'm +1 about making asyncfswal as default in 2.0 :-) Best Regards, Yu On 6 May 2016 at 09:49, Ted Yu wrote: > Thanks for your effort, Duo. > > I am in favor of turning AsyncWAL as default in master branch. > > Cheers > > On Thu, May 5, 2016 at 6:03 PM, 张铎 wrote: > > > Some progress. > > > > I have filed HBASE-15743 for the transparent encryption support, > > and HBASE-15754 for the AES encryption UT. Now both of them are resolved. > > Let's resume the discussion here. > > > > Thanks. > > > > 2016-05-03 10:09 GMT+08:00 张铎 : > > > > > Fine, will add the testcase. > > > > > > And for the RPC, we only implement a new client side DTP here and still > > > use the original RPC. > > > > > > Thanks. > > > > > > 2016-05-03 3:20 GMT+08:00 Gary Helmling : > > > > > >> On Fri, Apr 29, 2016 at 6:24 PM 张铎 wrote: > > >> > > >> > Yes, it does. There is testcase that enumerates all the possible > > >> protection > > >> > level(authentication, integrity and privacy) and encryption > > >> algorithm(none, > > >> > 3des, rc4). > > >> > > > >> > > > >> > > > >> > > > https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/io/asyncfs/TestSaslFanOutOneBlockAsyncDFSOutput.java > > >> > > > >> > I have also tested it in a secure cluster(hbase-2.0.0-SNAPSHOT and > > >> > hadoop-2.4.0). > > >> > > > >> > > >> Thanks. Can you add in support for testing with AES > > >> (dfs.encrypt.data.transfer.cipher.suites=AES/CTR/NoPadding)? This is > > only > > >> available in Hadoop 2.6.0+, but I think is far more likely to be used > in > > >> production than 3des or rc4. > > > > > > > > >> Also, have you been following HADOOP-10768? That is changing Hadoop > RPC > > >> encryption negotiation to support more performant AES wrapping, > similar > > to > > >> what is now supported in the data transfer pipeline. > > >> > > > > > > > > >
Re: [DISCUSS] Make AsyncFSWAL the default WAL in 2.0
Thanks for your effort, Duo. I am in favor of turning AsyncWAL as default in master branch. Cheers On Thu, May 5, 2016 at 6:03 PM, 张铎 wrote: > Some progress. > > I have filed HBASE-15743 for the transparent encryption support, > and HBASE-15754 for the AES encryption UT. Now both of them are resolved. > Let's resume the discussion here. > > Thanks. > > 2016-05-03 10:09 GMT+08:00 张铎 : > > > Fine, will add the testcase. > > > > And for the RPC, we only implement a new client side DTP here and still > > use the original RPC. > > > > Thanks. > > > > 2016-05-03 3:20 GMT+08:00 Gary Helmling : > > > >> On Fri, Apr 29, 2016 at 6:24 PM 张铎 wrote: > >> > >> > Yes, it does. There is testcase that enumerates all the possible > >> protection > >> > level(authentication, integrity and privacy) and encryption > >> algorithm(none, > >> > 3des, rc4). > >> > > >> > > >> > > >> > https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/io/asyncfs/TestSaslFanOutOneBlockAsyncDFSOutput.java > >> > > >> > I have also tested it in a secure cluster(hbase-2.0.0-SNAPSHOT and > >> > hadoop-2.4.0). > >> > > >> > >> Thanks. Can you add in support for testing with AES > >> (dfs.encrypt.data.transfer.cipher.suites=AES/CTR/NoPadding)? This is > only > >> available in Hadoop 2.6.0+, but I think is far more likely to be used in > >> production than 3des or rc4. > > > > > >> Also, have you been following HADOOP-10768? That is changing Hadoop RPC > >> encryption negotiation to support more performant AES wrapping, similar > to > >> what is now supported in the data transfer pipeline. > >> > > > > >
Re: [DISCUSS] Make AsyncFSWAL the default WAL in 2.0
Some progress. I have filed HBASE-15743 for the transparent encryption support, and HBASE-15754 for the AES encryption UT. Now both of them are resolved. Let's resume the discussion here. Thanks. 2016-05-03 10:09 GMT+08:00 张铎 : > Fine, will add the testcase. > > And for the RPC, we only implement a new client side DTP here and still > use the original RPC. > > Thanks. > > 2016-05-03 3:20 GMT+08:00 Gary Helmling : > >> On Fri, Apr 29, 2016 at 6:24 PM 张铎 wrote: >> >> > Yes, it does. There is testcase that enumerates all the possible >> protection >> > level(authentication, integrity and privacy) and encryption >> algorithm(none, >> > 3des, rc4). >> > >> > >> > >> https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/io/asyncfs/TestSaslFanOutOneBlockAsyncDFSOutput.java >> > >> > I have also tested it in a secure cluster(hbase-2.0.0-SNAPSHOT and >> > hadoop-2.4.0). >> > >> >> Thanks. Can you add in support for testing with AES >> (dfs.encrypt.data.transfer.cipher.suites=AES/CTR/NoPadding)? This is only >> available in Hadoop 2.6.0+, but I think is far more likely to be used in >> production than 3des or rc4. > > >> Also, have you been following HADOOP-10768? That is changing Hadoop RPC >> encryption negotiation to support more performant AES wrapping, similar to >> what is now supported in the data transfer pipeline. >> > >
Re: Hangouts for C++ client discussions
On Thu, May 5, 2016 at 9:22 AM, Elliott Clark wrote: > ...One other thing I would like to call out, is > that since the c++ client is new code, it really needs all the code reviews > that it can get. If you have some c++ knowledge please come on over to > https://issues.apache.org/jira/browse/HBASE-14850 and lets work to make > the > code better. > > +1 St.Ack > Thanks > > On Wed, May 4, 2016 at 9:37 PM, Stack wrote: > > > On Tue, May 3, 2016 at 11:57 AM, Enis Söztutar wrote: > > > > > Devs, > > > > > > If you have been following, we have two initiatives for writing a C++ > > > client for HBase. We are planning on doing a hangouts tomorrow, Wed > > 10-11am > > > PDT to discuss various things related to the efforts. Please feel free > to > > > join if you are interested. > > > > > > The proposed agenda is here: > > > > > > > > > https://docs.google.com/document/d/10O626jxK6f7nmdBjG0h9f_PYkbWNMGKH0-1H1i6SmaU/edit > > > > > > > > > Hangouts link is here: > > > https://hangouts.google.com/call/lige2qdmyfakrbzacfcafhzrh4e > > > > > > Enis > > > > > > > Here are notes from today's productive discussion [1][2]. The meeting's > > working objective was how we as a community could align on a single C++ > > client. Toward the end of the notes are suggested ways on how we might > > attain this stated objective repeated below (see doc for full context and > > discussion that led up to the below list). > > > > "Suggestions for how to go forward (pending feedback from community) > > > > + Moving everything into the [open on the] 14850 branch > > + Vamsi [lead on one of the two C++ projects] is going to try break[ing] > up > > his [patch into] sync/async API > > + Patches [to be made] for build system and XML > > + Targeting basic client functionally, Get/Put/Scan [at first with rest > to > > follow later] > > + Ok with sync and async API > > + Sync most likely based on async > > + [Will start a discussion soon on the m]erge criteria for the [14850] > > branch" > > > > Thanks, > > St.Ack > > > > 1. > > > > > https://docs.google.com/document/d/10O626jxK6f7nmdBjG0h9f_PYkbWNMGKH0-1H1i6SmaU/edit?ts=572a3ce1# > > 2. https://paste.apache.org/7lCa > > >
[jira] [Created] (HBASE-15782) TestShell fails due to some moved types
Ted Yu created HBASE-15782:
--
Summary: TestShell fails due to some moved types
Key: HBASE-15782
URL: https://issues.apache.org/jira/browse/HBASE-15782
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
{code}
1) Error:
test_compact_should_work(Hbase::AdminMethodsTest):
NameError: uninitialized constant
Java::OrgApacheHadoopHbaseClient::Admin::CompactType
org/jruby/RubyModule.java:2647:in `const_missing'
file:/home/hbase/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/META-INF/jruby.home/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in
`const_missing'
/home/hbase/trunk/hbase-shell/src/main/ruby/hbase/admin.rb:71:in `compact'
./src/test/ruby/hbase/admin_test.rb:106:in `test_compact_should_work'
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'
2) Error:
test_major_compact_should_work(Hbase::AdminMethodsTest):
NameError: uninitialized constant
Java::OrgApacheHadoopHbaseClient::Admin::CompactType
org/jruby/RubyModule.java:2647:in `const_missing'
file:/home/hbase/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/META-INF/jruby.home/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2503:in
`const_missing'
/home/hbase/trunk/hbase-shell/src/main/ruby/hbase/admin.rb:99:in
`major_compact'
./src/test/ruby/hbase/admin_test.rb:112:in `test_major_compact_should_work'
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'
3) Error:
test_Snapshot_should_work_when_SKIP_FLUSH_args(Hbase::AdminSnapshotTest):
NameError: no method 'snapshot' for arguments
(org.jruby.RubyString,org.apache.hadoop.hbase.TableName,org.apache.hadoop.hbase.protobuf.generated.HBaseProtos.SnapshotDescription.
Type) on Java::OrgApacheHadoopHbaseClient::HBaseAdmin
/home/hbase/trunk/hbase-shell/src/main/ruby/hbase/admin.rb:957:in `snapshot'
org/jruby/RubyArray.java:1620:in `each'
/home/hbase/trunk/hbase-shell/src/main/ruby/hbase/admin.rb:955:in `snapshot'
./src/test/ruby/hbase/admin_test.rb:450:in
`test_Snapshot_should_work_when_SKIP_FLUSH_args'
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'
382 tests, 537 assertions, 0 failures, 3 errors
{code}
The above were due to certain types being moved so that we don't expose
protobuf in API
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15781) Remove unused TableEventHandler and TotesHRegionInfo
Matteo Bertozzi created HBASE-15781: --- Summary: Remove unused TableEventHandler and TotesHRegionInfo Key: HBASE-15781 URL: https://issues.apache.org/jira/browse/HBASE-15781 Project: HBase Issue Type: Bug Components: master Affects Versions: 2.0.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Trivial Fix For: 2.0.0 Attachments: HBASE-15781-v0.patch Remove unused classes TableEventHandler and TotesHRegionInfo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15780) Expose AuthUtil as IA.Public
Sean Busbey created HBASE-15780: --- Summary: Expose AuthUtil as IA.Public Key: HBASE-15780 URL: https://issues.apache.org/jira/browse/HBASE-15780 Project: HBase Issue Type: New Feature Components: API, security Reporter: Sean Busbey Assignee: Sean Busbey Priority: Critical Fix For: 2.0.0, 1.4.0 Make AuthUtils IA.Public so that we can point it out to folks who want to build long-lived services that talk to secure HBase clusters without concerning them with Hadoop APIs like UGI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15779) Examples should use programmatic keytab auth
Sean Busbey created HBASE-15779: --- Summary: Examples should use programmatic keytab auth Key: HBASE-15779 URL: https://issues.apache.org/jira/browse/HBASE-15779 Project: HBase Issue Type: Improvement Components: documentation Reporter: Sean Busbey Assignee: Sean Busbey Fix For: 2.0.0, 1.4.0 our examples should include programmatic keytab-based access for secure hbase clusters, since most folks who look at them for building long-lived services will need to take that approach rather than an external kinit-and-refresh process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15778) replace master.am and master.sm direct access with getter calls
Matteo Bertozzi created HBASE-15778: --- Summary: replace master.am and master.sm direct access with getter calls Key: HBASE-15778 URL: https://issues.apache.org/jira/browse/HBASE-15778 Project: HBase Issue Type: Sub-task Components: master Affects Versions: 2.0.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Trivial Fix For: 2.0.0 MasterRpcServices seems to access directly a bunch of members of HMaster. I think this is because when we split HMaster and MaterRpcServices we just did a find & replace. I was trying to mock and have a different AssignmentManager and ServerManager but it got impossible with those access directly. so, here a patch to avoid the direct access to AM and SM. There are many more members that can be made private but I'm lazy. so this pass is only AM, SM related -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15777) Fix needs header in client handler
Elliott Clark created HBASE-15777: - Summary: Fix needs header in client handler Key: HBASE-15777 URL: https://issues.apache.org/jira/browse/HBASE-15777 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Assignee: Elliott Clark This needs to be a little more complex or there could be a request sent before the header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15776) Replace master.am.getTableStateManager() with the direct master.getTableStateManager()
Matteo Bertozzi created HBASE-15776: --- Summary: Replace master.am.getTableStateManager() with the direct master.getTableStateManager() Key: HBASE-15776 URL: https://issues.apache.org/jira/browse/HBASE-15776 Project: HBase Issue Type: Sub-task Components: master Affects Versions: 2.0.0 Reporter: Matteo Bertozzi Assignee: Matteo Bertozzi Priority: Trivial Fix For: 2.0.0 Attachments: HBASE-15776-v0.patch Replace the double lookup master.getAssignmentManager().getTableStateManager() with the direct master.getTableStateManager(). this also because I'd like to remove the TableStateManager instance from the new AM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15775) Canary launches two AuthUtil Chores
Sean Busbey created HBASE-15775: --- Summary: Canary launches two AuthUtil Chores Key: HBASE-15775 URL: https://issues.apache.org/jira/browse/HBASE-15775 Project: HBase Issue Type: Bug Components: canary Affects Versions: 0.98.19, 0.98.16.1, 0.98.18, 0.98.17, 0.98.16, 1.2.1, 0.98.15, 1.2.0, 0.98.14, 0.98.13 Reporter: Sean Busbey Fix For: 1.2.2, 0.98.20 Looks like a result of an error in backport done in HBASE-13712. We have a AuthUtil chore both in main() and in run(). The one in main() should be removed so that the code is consistent with other branches. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15774) Fix Upgrade lock usage in connection pool.
Elliott Clark created HBASE-15774: - Summary: Fix Upgrade lock usage in connection pool. Key: HBASE-15774 URL: https://issues.apache.org/jira/browse/HBASE-15774 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Just do double checked locking. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15773) CellCounter improvements
Gary Helmling created HBASE-15773: - Summary: CellCounter improvements Key: HBASE-15773 URL: https://issues.apache.org/jira/browse/HBASE-15773 Project: HBase Issue Type: Improvement Components: mapreduce Reporter: Gary Helmling Looking at the CellCounter map reduce, it seems like it can be improved in a few areas: * it does not currently support setting scan batching. This is important when we're fetching all versions for columns. Actually, it would be nice to support all of the scan configuration currently provided in TableInputFormat. * generating job counters containing row keys and column qualifiers is guaranteed to blow up on anything but the smallest table. This is not usable and doesn't make any sense when the same counts are in the job output. The row and qualifier specific counters should be dropped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Hangouts for C++ client discussions
Thanks for taking notes Stack. One other thing I would like to call out, is that since the c++ client is new code, it really needs all the code reviews that it can get. If you have some c++ knowledge please come on over to https://issues.apache.org/jira/browse/HBASE-14850 and lets work to make the code better. Thanks On Wed, May 4, 2016 at 9:37 PM, Stack wrote: > On Tue, May 3, 2016 at 11:57 AM, Enis Söztutar wrote: > > > Devs, > > > > If you have been following, we have two initiatives for writing a C++ > > client for HBase. We are planning on doing a hangouts tomorrow, Wed > 10-11am > > PDT to discuss various things related to the efforts. Please feel free to > > join if you are interested. > > > > The proposed agenda is here: > > > > > https://docs.google.com/document/d/10O626jxK6f7nmdBjG0h9f_PYkbWNMGKH0-1H1i6SmaU/edit > > > > > > Hangouts link is here: > > https://hangouts.google.com/call/lige2qdmyfakrbzacfcafhzrh4e > > > > Enis > > > > Here are notes from today's productive discussion [1][2]. The meeting's > working objective was how we as a community could align on a single C++ > client. Toward the end of the notes are suggested ways on how we might > attain this stated objective repeated below (see doc for full context and > discussion that led up to the below list). > > "Suggestions for how to go forward (pending feedback from community) > > + Moving everything into the [open on the] 14850 branch > + Vamsi [lead on one of the two C++ projects] is going to try break[ing] up > his [patch into] sync/async API > + Patches [to be made] for build system and XML > + Targeting basic client functionally, Get/Put/Scan [at first with rest to > follow later] > + Ok with sync and async API > + Sync most likely based on async > + [Will start a discussion soon on the m]erge criteria for the [14850] > branch" > > Thanks, > St.Ack > > 1. > > https://docs.google.com/document/d/10O626jxK6f7nmdBjG0h9f_PYkbWNMGKH0-1H1i6SmaU/edit?ts=572a3ce1# > 2. https://paste.apache.org/7lCa >
[jira] [Created] (HBASE-15772) Switch to the new RegionObserver#preStoreScannerOpen() method which accepts read point parameter
Ted Yu created HBASE-15772:
--
Summary: Switch to the new RegionObserver#preStoreScannerOpen()
method which accepts read point parameter
Key: HBASE-15772
URL: https://issues.apache.org/jira/browse/HBASE-15772
Project: HBase
Issue Type: Task
Reporter: Ted Yu
Over in HBASE-15759, the following method is added to RegionObserver :
{code}
public KeyValueScanner preStoreScannerOpen(final
ObserverContext c,
final Store store, final Scan scan, final NavigableSet targetCols,
final KeyValueScanner s, final long readPt) throws IOException {
{code}
Currently the preStoreScannerOpen() without read point parameter is used in
IndexHalfStoreFileReaderGenerator
We need to switch over to calling the new method for hbase 2.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15771) Document all the public classes
Elliott Clark created HBASE-15771: - Summary: Document all the public classes Key: HBASE-15771 URL: https://issues.apache.org/jira/browse/HBASE-15771 Project: HBase Issue Type: Sub-task Reporter: Elliott Clark Add on doxygen comments for all public classes and methods. Once that's done then we can turn on doxygen with error on missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Successful: HBase Generate Website
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/220/artifact/website.patch.zip
| funzip > d23d600d768cd73125d5be62b7b8e3fa6fac5761.patch
git fetch
git checkout -b asf-site-d23d600d768cd73125d5be62b7b8e3fa6fac5761
origin/asf-site
git am --whitespace=fix d23d600d768cd73125d5be62b7b8e3fa6fac5761.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-d23d600d768cd73125d5be62b7b8e3fa6fac5761 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 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 this
command:
git push origin asf-site-d23d600d768cd73125d5be62b7b8e3fa6fac5761:asf-site
Changes take a couple of minutes to be propagated. You can then remove your
asf-site-d23d600d768cd73125d5be62b7b8e3fa6fac5761 branch:
git checkout asf-site && git branch -d
asf-site-d23d600d768cd73125d5be62b7b8e3fa6fac5761
If failed, see https://builds.apache.org/job/hbase_generate_website/220/console
