[jira] [Created] (HBASE-18149) The setting rules for table-scope attributes and family-scope attributes should keep consistent

2017-06-01 Thread Guangxu Cheng (JIRA) 
Guangxu Cheng created HBASE-18149:
-

 Summary: The setting rules for table-scope attributes and 
family-scope attributes should keep consistent
 Key: HBASE-18149
 URL: https://issues.apache.org/jira/browse/HBASE-18149
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 1.2.5, 2.0.0
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng


I use the following command to create a table.

{code}
hbase(main):030:0> create 't3',{NAME => 'f2', BLOCKCACHE => false}, 
{COMPACTION_ENABLED => false}
An argument ignored (unknown or overridden): COMPACTION_ENABLED
0 row(s) in 1.1390 seconds

hbase(main):031:0> describe 't3'
Table t3 is ENABLED
t3  

 
COLUMN FAMILIES DESCRIPTION 

 
{NAME => 'f2', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false', 
KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', 
COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'false', BLOCKSIZE => 
'65536', REPLICATION_SCOPE => '0'}
1 row(s) in 0.0720 seconds
{code}

*BLOCKCACHE* was in effect but *COMPACTION_ENABLED* didn't take effect.
After checking code, I found that if the table-scope attributes value is false, 
you need to enclose 'false' in single quotation marks while family-scope is not 
required.
so we should keep the consistent logic for table-scope and family-scope.
the command alter also have the same problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-16543) Separate Create/Modify Table operations from open/reopen regions

2017-06-01 Thread Umesh Agashe (JIRA) 

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

Umesh Agashe resolved HBASE-16543.
--
Resolution: Fixed

> Separate Create/Modify Table operations from open/reopen regions
> 
>
> Key: HBASE-16543
> URL: https://issues.apache.org/jira/browse/HBASE-16543
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0
>
>
> At the moment create table and modify table operations will trigger an 
> open/reopen of the regions inside the DDL operation. 
> we should split the operation in two parts
>  - create table, enable table regions
>  - modify table, reopen table regions



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-16543) Separate Create/Modify Table operations from open/reopen regions

2017-06-01 Thread Umesh Agashe (JIRA) 

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

Umesh Agashe resolved HBASE-16543.
--
Resolution: Fixed

Fixed by HBASE-14614.

> Separate Create/Modify Table operations from open/reopen regions
> 
>
> Key: HBASE-16543
> URL: https://issues.apache.org/jira/browse/HBASE-16543
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0
>
>
> At the moment create table and modify table operations will trigger an 
> open/reopen of the regions inside the DDL operation. 
> we should split the operation in two parts
>  - create table, enable table regions
>  - modify table, reopen table regions



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (HBASE-16543) Separate Create/Modify Table operations from open/reopen regions

2017-06-01 Thread Umesh Agashe (JIRA) 

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

Umesh Agashe reopened HBASE-16543:
--

> Separate Create/Modify Table operations from open/reopen regions
> 
>
> Key: HBASE-16543
> URL: https://issues.apache.org/jira/browse/HBASE-16543
> Project: HBase
>  Issue Type: Sub-task
>  Components: master
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 2.0.0
>
>
> At the moment create table and modify table operations will trigger an 
> open/reopen of the regions inside the DDL operation. 
> we should split the operation in two parts
>  - create table, enable table regions
>  - modify table, reopen table regions



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] First release candidate for HBase 1.2.6 is available

2017-06-01 Thread Sean Busbey 
On Thu, Jun 1, 2017 at 1:13 PM, Alexander Leblang
 wrote:
> If you wouldn't mind, I'd like some more time. I'm working on using
> clusterdock to run some testing on the candidate.
>
> - Alex
>

Sounds great Alex, I'll hold off. Feel free to ping the list if you
get stuck on clusterdock. I think it's been a while since any of us
have dug in, but hopefully we can still help.

-- 
Sean

Re: [VOTE] First release candidate for HBase 1.2.6 is available

2017-06-01 Thread Andrew Purtell 
Seconded!
This is a great vote.

On Thu, Jun 1, 2017 at 11:11 AM, Sean Busbey  wrote:

> Originally I said Monday June 5th, but I wasn't expecting such a
> strong response. :)
>
> Anyone still need time? We're past the required 72 hour minimum.
>
> On Mon, May 29, 2017 at 11:31 AM, Sean Busbey  wrote:
> > The first release candidate for HBase 1.2.6 is available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.6RC0/
> >
> > Maven artifacts are also available in a staging repository at:
> >
> > https://repository.apache.org/content/repositories/orgapachehbase-1168/
> >
> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> > file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 1.2.6RC0, which currently points
> > to commit ref
> >
> > 2f9b9e17d0522e36063bf52ecc58576243d20b3f
> >
> > The detailed source and binary compatibility report vs 1.2.5 has been
> > published for your review, at:
> >
> > https://s.apache.org/hbase-1.2.6-rc0-compat-report
> >
> > HBase 1.2.6 is the sixth maintenance release in the HBase 1.2 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. This release includes over 25
> > bug fixes since 1.2.5.
> >
> > Critical fixes include:
> >
> > * HBASE-17287 - Master becomes a zombie if filesystem object closes
> > * HBASE-16630 - Fragmentation in long running Bucket Cache
> > * HBASE-17717 - Incorrect ZK ACL set for HBase superuser
> > * HBASE-15941 - HBCK repair should not unsplit healthy splitted region
> >
> > The full list of fixes included in this release is available at:
> >
> > https://s.apache.org/hbase-1.2.6-jira-release-notes
> >
> > and in the CHANGES.txt file included in the distribution.
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 1.2.6.
> >
> > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > I would like to close it on June 5th, 2017.
> >
> > thanks!
>



-- 
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)

Re: [VOTE] First release candidate for HBase 1.2.6 is available

2017-06-01 Thread Alexander Leblang 
If you wouldn't mind, I'd like some more time. I'm working on using
clusterdock to run some testing on the candidate.

- Alex

On Thu, Jun 1, 2017 at 11:11 AM, Sean Busbey  wrote:

> Originally I said Monday June 5th, but I wasn't expecting such a
> strong response. :)
>
> Anyone still need time? We're past the required 72 hour minimum.
>
> On Mon, May 29, 2017 at 11:31 AM, Sean Busbey  wrote:
> > The first release candidate for HBase 1.2.6 is available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.6RC0/
> >
> > Maven artifacts are also available in a staging repository at:
> >
> > https://repository.apache.org/content/repositories/orgapachehbase-1168/
> >
> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
> > file at http://www.apache.org/dist/hbase/KEYS
> >
> > The RC corresponds to the signed tag 1.2.6RC0, which currently points
> > to commit ref
> >
> > 2f9b9e17d0522e36063bf52ecc58576243d20b3f
> >
> > The detailed source and binary compatibility report vs 1.2.5 has been
> > published for your review, at:
> >
> > https://s.apache.org/hbase-1.2.6-rc0-compat-report
> >
> > HBase 1.2.6 is the sixth maintenance release in the HBase 1.2 line,
> > continuing on the theme of bringing a stable, reliable database to
> > the Hadoop and NoSQL communities. This release includes over 25
> > bug fixes since 1.2.5.
> >
> > Critical fixes include:
> >
> > * HBASE-17287 - Master becomes a zombie if filesystem object closes
> > * HBASE-16630 - Fragmentation in long running Bucket Cache
> > * HBASE-17717 - Incorrect ZK ACL set for HBase superuser
> > * HBASE-15941 - HBCK repair should not unsplit healthy splitted region
> >
> > The full list of fixes included in this release is available at:
> >
> > https://s.apache.org/hbase-1.2.6-jira-release-notes
> >
> > and in the CHANGES.txt file included in the distribution.
> >
> > Please try out this candidate and vote +1/-1 on whether we should
> > release these artifacts as HBase 1.2.6.
> >
> > The VOTE will remain open for at least 72 hours. Given sufficient votes
> > I would like to close it on June 5th, 2017.
> >
> > thanks!
>

Re: [VOTE] First release candidate for HBase 1.2.6 is available

2017-06-01 Thread Sean Busbey 
Originally I said Monday June 5th, but I wasn't expecting such a
strong response. :)

Anyone still need time? We're past the required 72 hour minimum.

On Mon, May 29, 2017 at 11:31 AM, Sean Busbey  wrote:
> The first release candidate for HBase 1.2.6 is available for download at:
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.6RC0/
>
> Maven artifacts are also available in a staging repository at:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1168/
>
> Artifacts are signed with my key (0D80DB7C) published in our KEYS
> file at http://www.apache.org/dist/hbase/KEYS
>
> The RC corresponds to the signed tag 1.2.6RC0, which currently points
> to commit ref
>
> 2f9b9e17d0522e36063bf52ecc58576243d20b3f
>
> The detailed source and binary compatibility report vs 1.2.5 has been
> published for your review, at:
>
> https://s.apache.org/hbase-1.2.6-rc0-compat-report
>
> HBase 1.2.6 is the sixth maintenance release in the HBase 1.2 line,
> continuing on the theme of bringing a stable, reliable database to
> the Hadoop and NoSQL communities. This release includes over 25
> bug fixes since 1.2.5.
>
> Critical fixes include:
>
> * HBASE-17287 - Master becomes a zombie if filesystem object closes
> * HBASE-16630 - Fragmentation in long running Bucket Cache
> * HBASE-17717 - Incorrect ZK ACL set for HBase superuser
> * HBASE-15941 - HBCK repair should not unsplit healthy splitted region
>
> The full list of fixes included in this release is available at:
>
> https://s.apache.org/hbase-1.2.6-jira-release-notes
>
> and in the CHANGES.txt file included in the distribution.
>
> Please try out this candidate and vote +1/-1 on whether we should
> release these artifacts as HBase 1.2.6.
>
> The VOTE will remain open for at least 72 hours. Given sufficient votes
> I would like to close it on June 5th, 2017.
>
> thanks!

[jira] [Created] (HBASE-18148) automated tests against non-minicluster based deployment

2017-06-01 Thread Sean Busbey (JIRA) 
Sean Busbey created HBASE-18148:
---

 Summary: automated tests against non-minicluster based deployment
 Key: HBASE-18148
 URL: https://issues.apache.org/jira/browse/HBASE-18148
 Project: HBase
  Issue Type: Test
  Components: community, integration tests
Reporter: Sean Busbey


we should have ITs that run automatically (i.e. nightly) against a cluster that 
isn't a minicluster or standalone instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-18147) nightly job to check health of active branches

2017-06-01 Thread Sean Busbey (JIRA) 
Sean Busbey created HBASE-18147:
---

 Summary: nightly job to check health of active branches
 Key: HBASE-18147
 URL: https://issues.apache.org/jira/browse/HBASE-18147
 Project: HBase
  Issue Type: Test
  Components: community, test
Reporter: Sean Busbey


We should set up a job that runs Apache Yetus Test Patch's nightly mode. 
Essentially, it produces a report that considers how the branch measures up 
against the things we check in our precommit checks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HBASE-18146) Long running integration test similar to TestAcidGuarantees

2017-06-01 Thread Andrew Purtell (JIRA) 
Andrew Purtell created HBASE-18146:
--

 Summary: Long running integration test similar to 
TestAcidGuarantees
 Key: HBASE-18146
 URL: https://issues.apache.org/jira/browse/HBASE-18146
 Project: HBase
  Issue Type: Test
  Components: integration tests
Reporter: Andrew Purtell


TestAcidGuarantees and IntegrationTestAcidGuarantees both really only work with 
minicluster based testing and do not run for a long duration. Consider a new 
integration test that makes similar atomicity checks while running for, 
potentially, a very long time, determined by test parameters supplied on the 
command line (perhaps as property definitions). The new integration test should 
expect to run against a distributed cluster, support specification of desired 
monkey policy, and not require any special non-default site configuration 
settings. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-15487) Deletions done via BulkDeleteEndpoint make past data re-appear

2017-06-01 Thread Zheng Hu (JIRA) 

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

Zheng Hu resolved HBASE-15487.
--
Resolution: Duplicate

> Deletions done via BulkDeleteEndpoint make past data re-appear
> --
>
> Key: HBASE-15487
> URL: https://issues.apache.org/jira/browse/HBASE-15487
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.0.3
>Reporter: Mathias Herberts
> Attachments: HBaseTest.java, HBaseTest.java
>
>
> The Warp10 (www.warp10.io) time series database uses HBase as its underlying 
> data store. The deletion of ranges of cells is performed using the 
> BulkDeleteEndpoint.
> In the following scenario the deletion does not appear to be working properly:
> The table 't' is created with a single version using:
> create 't', {NAME => 'v', DATA_BLOCK_ENCODING => 'FAST_DIFF', BLOOMFILTER => 
> 'NONE', REPLICATION_SCOPE => '0', VERSIONS=> '1', MIN_VERSIONS => '0', TTL => 
> '2147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY 
> =>'false', BLOCKCACHE => 'true'}
> We write a cell at row '0x00', colfam 'v', colq '', value 0x0
> We write the same cell again with value 0x1
> A scan will return a single value 0x1
> We then perform a delete using the BulkDeleteEndpoint and a Scan with a 
> DeleteType of 'VERSION'
> The reported number of deleted versions is 1 (which is coherent given the 
> table was created with MAX_VERSIONS=1)
> The same scan as the one performed before the delete returns a single value 
> 0x0.
> This seems to happen when all operations are performed against the memstore.
> A regular delete will remove the cell and a later scan won't show it.
> I'll attach a test which demonstrates the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (HBASE-3462) Fix table.jsp in regards to splitting a region/table with an optional splitkey

2017-06-01 Thread Sean Busbey (JIRA) 

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

Sean Busbey resolved HBASE-3462.

  Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed  (was: Reviewed)
Release Note: UI pages for splitting/merging now operate by taking a row 
key prefix from the user rather than a full region name.

> Fix table.jsp in regards to splitting a region/table with an optional splitkey
> --
>
> Key: HBASE-3462
> URL: https://issues.apache.org/jira/browse/HBASE-3462
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 0.90.0
>Reporter: Lars George
>Assignee: Balazs Meszaros
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-3462-BM-01.patch, HBASE-3462-BM-01.patch
>
>
> After HBASE-3328 and HBASE-3437 went in there is also the table.jsp that 
> needs updating to support the same features. Also, at the same time update 
> the wording, for example 
> {quote}
> This action will force a split of all eligible regions of the table, or, if a 
> key is supplied, only the region containing the given key. An eligible region 
> is one that does not contain any references to other regions. Split requests 
> for noneligible regions will be ignored.
> {quote}
> I think it means it splits either all regions (that are splittable) or a 
> specific one. It says though "the region containing the given key", that 
> seems wrong in any event. Currently we do a split on the tablename when 
> nothing was specified or else do an internal get(region), which is an exact 
> match on the rows in .META.. In other words you need to match the region name 
> exactly or else it fails. It reports it has accepted the request but logs 
> internally
> {code}
> 2011-01-21 15:37:24,340 INFO org.apache.hadoop.hbase.client.HBaseAdmin: No 
> server in .META. for csfsef; pair=null
> {code}
> Error reporting could be better but because of the async nature this is more 
> difficult, yet it would be nice there is some concept of a Future to be able 
> to poll the result if needed.
> Finally, when you go back to the previous page after submitting the split the 
> entered values show up in the "compact" input fields, at least on my Chrome. 
> The inputs in both forms are named the same so it seems to confuse it. This 
> could be improved a lot by making the landing page reload the main one 
> automatically or refresh on reload instead of submitting the request again.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] First release candidate for HBase 1.2.6 is available

2017-06-01 Thread Sean Busbey 
The text of HBASE-3462 suggests that the UI shipped in branch-1 works
by taking a region name rather than part of a row. The exception you
got also points to expecting a region name.

I think for branch-1 releases, a JIRA to update the text to match
what's actually expected is a good idea. The behavior has been present
for so long that it seems unwise to change it in a non-major release.

On Wed, May 31, 2017 at 10:48 PM, Guanghao Zhang  wrote:
> hbase-1.2.6-bin.tar.gz
> - Verified md5sum: ok
> - Start HBase in standalone mode: ok
> - Verified with shell, create/disable/enable/drop/get/put/scan/delete: ok
> - Checked master/regionserver/table Web UI and found a problem: Table UI,
> split/compact not work with a given key. It was fixed by HBASE-3462. But
> the fix was only merged to master branch. I thought this is a bug fix so it
> should be merged to branch-1.2, too?
>
> Exception:
> java.lang.IllegalArgumentException: Invalid region: 50
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.splitRegion(HBaseAdmin.java:2668)
> at
> org.apache.hadoop.hbase.client.HBaseAdmin.splitRegion(HBaseAdmin.java:2605)
> at
> org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:127)
>
> Thanks.
>
> 2017-05-31 23:38 GMT+08:00 Andrew Purtell :
>
>> +1
>>
>> Checked sums and signatures: ok
>> Unpacked tarballs, layout looks good
>> Built from source: ok (7u80)
>> RAT check passes: ok (7u80)
>> Unit test passes: ok (7u80)
>> Loaded 1M rows with LTT: ok, all keys verified, latencies in the ballpark,
>> no unusual messages or warnings (8u121)
>> API compatibility report looks good
>>
>>
>> On Mon, May 29, 2017 at 9:31 AM, Sean Busbey  wrote:
>>
>> > The first release candidate for HBase 1.2.6 is available for download at:
>> >
>> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.2.6RC0/
>> >
>> > Maven artifacts are also available in a staging repository at:
>> >
>> > https://repository.apache.org/content/repositories/orgapachehbase-1168/
>> >
>> > Artifacts are signed with my key (0D80DB7C) published in our KEYS
>> > file at http://www.apache.org/dist/hbase/KEYS
>> >
>> > The RC corresponds to the signed tag 1.2.6RC0, which currently points
>> > to commit ref
>> >
>> > 2f9b9e17d0522e36063bf52ecc58576243d20b3f
>> >
>> > The detailed source and binary compatibility report vs 1.2.5 has been
>> > published for your review, at:
>> >
>> > https://s.apache.org/hbase-1.2.6-rc0-compat-report
>> >
>> > HBase 1.2.6 is the sixth maintenance release in the HBase 1.2 line,
>> > continuing on the theme of bringing a stable, reliable database to
>> > the Hadoop and NoSQL communities. This release includes over 25
>> > bug fixes since 1.2.5.
>> >
>> > Critical fixes include:
>> >
>> > * HBASE-17287 - Master becomes a zombie if filesystem object closes
>> > * HBASE-16630 - Fragmentation in long running Bucket Cache
>> > * HBASE-17717 - Incorrect ZK ACL set for HBase superuser
>> > * HBASE-15941 - HBCK repair should not unsplit healthy splitted region
>> >
>> > The full list of fixes included in this release is available at:
>> >
>> > https://s.apache.org/hbase-1.2.6-jira-release-notes
>> >
>> > and in the CHANGES.txt file included in the distribution.
>> >
>> > Please try out this candidate and vote +1/-1 on whether we should
>> > release these artifacts as HBase 1.2.6.
>> >
>> > The VOTE will remain open for at least 72 hours. Given sufficient votes
>> > I would like to close it on June 5th, 2017.
>> >
>> > thanks!
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>>- Andy
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>> Teller (via Peter Watts)
>>



-- 
Sean

[jira] [Reopened] (HBASE-3462) Fix table.jsp in regards to splitting a region/table with an optional splitkey

2017-06-01 Thread Sean Busbey (JIRA) 

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

Sean Busbey reopened HBASE-3462:


> Fix table.jsp in regards to splitting a region/table with an optional splitkey
> --
>
> Key: HBASE-3462
> URL: https://issues.apache.org/jira/browse/HBASE-3462
> Project: HBase
>  Issue Type: Improvement
>  Components: master
>Affects Versions: 0.90.0
>Reporter: Lars George
>Assignee: Balazs Meszaros
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-3462-BM-01.patch, HBASE-3462-BM-01.patch
>
>
> After HBASE-3328 and HBASE-3437 went in there is also the table.jsp that 
> needs updating to support the same features. Also, at the same time update 
> the wording, for example 
> {quote}
> This action will force a split of all eligible regions of the table, or, if a 
> key is supplied, only the region containing the given key. An eligible region 
> is one that does not contain any references to other regions. Split requests 
> for noneligible regions will be ignored.
> {quote}
> I think it means it splits either all regions (that are splittable) or a 
> specific one. It says though "the region containing the given key", that 
> seems wrong in any event. Currently we do a split on the tablename when 
> nothing was specified or else do an internal get(region), which is an exact 
> match on the rows in .META.. In other words you need to match the region name 
> exactly or else it fails. It reports it has accepted the request but logs 
> internally
> {code}
> 2011-01-21 15:37:24,340 INFO org.apache.hadoop.hbase.client.HBaseAdmin: No 
> server in .META. for csfsef; pair=null
> {code}
> Error reporting could be better but because of the async nature this is more 
> difficult, yet it would be nice there is some concept of a Future to be able 
> to poll the result if needed.
> Finally, when you go back to the previous page after submitting the split the 
> entered values show up in the "compact" input fields, at least on my Chrome. 
> The inputs in both forms are named the same so it seems to confuse it. This 
> could be improved a lot by making the landing page reload the main one 
> automatically or refresh on reload instead of submitting the request again.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Hadoop QA failed to build in branch-1 & branch-1.3

2017-06-01 Thread Sean Busbey 
Are we willing to switch to OpenJDK for our Java 7 tests?

Has anyone checked to see if there's an updated means for install JDK
7 from Oracle that works?

On Wed, May 31, 2017 at 11:25 PM, Ted Yu  wrote:
> Here is the action from hadoop to get around this problem: HADOOP-14474
>
> On Tue, May 30, 2017 at 8:26 PM, OpenInx  wrote:
>
>> The current problem is:  we got 404 not found returned when we install jdk7
>> ( Oracle Corp changed the jdk7 download link and need accept it's license &
>> login with oracle account ) .
>> Could we download  JDK7 from our own server, which is independent of
>> oracle's ?
>>
>> On Tue, May 30, 2017 at 10:38 PM, Mike Drob  wrote:
>>
>> > The anecdotal assumption is that Oracle JDK is more stable than OpenJDK,
>> > right? So shouldn't we be running tests with the OpenJDK. Kind of like a
>> > runner practicing with weights on their legs before the actual marathon.
>> >
>> > Mike
>> >
>> > On Sun, May 28, 2017 at 9:18 PM, Sean Busbey 
>> > wrote:
>> >
>> > > I first heard about the issue from Duo on JIRA, I do'nt know if anyone
>> > > has made a jira yet.
>> > >
>> > > The primary reason I can think of to test Oracle JDK instead of
>> > > OpenJDK is the presumption that the Oracle JDK will be more common in
>> > > production settings.
>> > >
>> > > We don't have, like, a survey of users@ to back that up of course.
>> > > ¯\_(ツ)_/¯
>> > >
>> > > On Sat, May 27, 2017 at 8:26 PM, Dima Spivak 
>> > > wrote:
>> > > > Oops, gotcha. Should have scrolled further below the checking out of
>> > the
>> > > > master branch; I see further below that it was the 1.3 job.
>> > > >
>> > > > Is there a JIRA to address the JDK package not being available, Sean?
>> > Any
>> > > > reason we insist upon using Oracle for these runs instead of the
>> > OpenJDK
>> > > > equivalent?
>> > > >
>> > > > On Sat, May 27, 2017 at 12:14 PM Sean Busbey 
>> > wrote:
>> > > >
>> > > >> Also, this is specifically when the per-branch docker image is
>> > > >> attempting to install the jdk(s) that are appropriate for the given
>> > > >> branch.
>> > > >>
>> > > >> like branch-1 that is mentioned above is here:
>> > > >>
>> > > >> https://github.com/apache/hbase/blob/branch-1/dev-
>> > > support/docker/Dockerfile
>> > > >>
>> > > >> On Sat, May 27, 2017 at 2:10 PM, Sean Busbey 
>> > wrote:
>> > > >> > Dima, the issue pointed out above is specific to the branch-1*
>> > > >> > branches that do support java 7. the master branch already doesn't
>> > do
>> > > >> > any java 7, which is why the failures don't happen on it.
>> > > >> >
>> > > >> > On Sat, May 27, 2017 at 11:58 AM, Dima Spivak <
>> > dimaspi...@apache.org>
>> > > >> wrote:
>> > > >> >> Hey there,
>> > > >> >>
>> > > >> >> The master branch actually doesn't support Java 7 at all, so we
>> > > should
>> > > >> >> remove that; good catch. Would you mind opening a JIRA for the
>> > issue
>> > > and
>> > > >> >> one of the members of the team with Jenkins access can address
>> it?
>> > > >> >>
>> > > >> >> On Sat, May 27, 2017 at 3:18 AM OpenInx 
>> wrote:
>> > > >> >>
>> > > >> >>> Hi Guys
>> > > >> >>>
>> > > >> >>> Seems like we always fail to install jdk7 for Hadoop QA
>> > currently. (
>> > > >> RUN
>> > > >> >>> apt-get -q update && apt-get -q install -y
>> oracle-java7-installer
>> > > >> failed)
>> > > >> >>>
>> > > >> >>> I'm not familiar with Hadoop QA environment,   Could anyone help
>> > to
>> > > (or
>> > > >> >>> tell how to)  fix it ?
>> > > >> >>>
>> > > >> >>> 1.  https://builds.apache.org/job/PreCommit-HBASE-Build/6921/
>> > > console
>> > > >> >>> 2.  https://builds.apache.org/job/PreCommit-HBASE-Build/6960/
>> > > console
>> > > >> >>> 3.  https://issues.apache.org/jira/browse/HBASE-18066?
>> > > >> >>> focusedCommentId=16025718=com.atlassian.jira.
>> > > >> >>> plugin.system.issuetabpanels:comment-tabpanel#comment-16025718
>> > > >> >>>
>> > > >> >>>
>> > > >> >>> Thanks.
>> > > >> >>>
>> > > >> >> --
>> > > >> >> -Dima
>> > > >>
>> > > > --
>> > > > -Dima
>> > >
>> > >
>> > >
>> > > --
>> > > Sean
>> > >
>> >
>>
>>
>>
>> --
>> ==
>> Openinx  blog : http://openinx.github.io
>>
>> TO BE A GREAT HACKER !
>> ==
>>

[jira] [Created] (HBASE-18145) The flush may cause the corrupt data for reading

2017-06-01 Thread Chia-Ping Tsai (JIRA) 
Chia-Ping Tsai created HBASE-18145:
--

 Summary: The flush may cause the corrupt data for reading
 Key: HBASE-18145
 URL: https://issues.apache.org/jira/browse/HBASE-18145
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai
Priority: Critical
 Fix For: 2.0.0


HBASE-18019 close the memstore after flush. The chuck which stores the current 
data may be reclaimed. So if the chuck is rewrited before we send the data to 
client, the client will receive the corrupt data.
This issue also breaks the TestAcid*.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)