[jira] [Resolved] (HBASE-17878) java.lang.NoSuchMethodError: org.joda.time.format.DateTimeFormatter.withZoneUTC()Lorg/joda/time/format/DateTimeFormatter when starting HBase with hbase.rootdir on S3

[Xiang Li (JIRA)]

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

Xiang Li resolved HBASE-17878.
--
Resolution: Duplicate

> java.lang.NoSuchMethodError: 
> org.joda.time.format.DateTimeFormatter.withZoneUTC()Lorg/joda/time/format/DateTimeFormatter
>  when starting HBase with hbase.rootdir on S3
> -
>
> Key: HBASE-17878
> URL: https://issues.apache.org/jira/browse/HBASE-17878
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-17878.master.000.patch, jruby-core-dep-tree.txt
>
>
> When setting up HBASE-17437 (Support specifying a WAL directory outside of 
> the root directory), we specify
> (1) hbase.rootdir on s3a
> (2) hbase.wal.dir on HDFS
> When starting HBase, the following exception is thrown:
> {code}
> Caused by: java.lang.NoSuchMethodError: 
> org.joda.time.format.DateTimeFormatter.withZoneUTC()Lorg/joda/time/format/DateTimeFormatter;
> at 
> com.amazonaws.auth.internal.AWS4SignerUtils.(AWS4SignerUtils.java:26)
> at 
> com.amazonaws.auth.internal.AWS4SignerRequestParams.(AWS4SignerRequestParams.java:85)
> at com.amazonaws.auth.AWS4Signer.sign(AWS4Signer.java:184)
> at 
> com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:709)
> at 
> com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:489)
> at 
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:310)
> at 
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3785)
> at 
> com.amazonaws.services.s3.AmazonS3Client.headBucket(AmazonS3Client.java:1107)
> at 
> com.amazonaws.services.s3.AmazonS3Client.doesBucketExist(AmazonS3Client.java:1070)
> at 
> org.apache.hadoop.fs.s3a.S3AFileSystem.initialize(S3AFileSystem.java:232)
> at 
> org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2669)
> at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:94)
> at 
> org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2703)
> at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2685)
> at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:373)
> at org.apache.hadoop.fs.Path.getFileSystem(Path.java:295)
> at org.apache.hadoop.hbase.util.FSUtils.getRootDir(FSUtils.java:1007)
> at 
> org.apache.hadoop.hbase.util.FSUtils.isValidWALRootDir(FSUtils.java:1050)
> at 
> org.apache.hadoop.hbase.util.FSUtils.getWALRootDir(FSUtils.java:1032)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.initializeFileSystem(HRegionServer.java:627)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:570)
> at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:393)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:2456)
> ... 5 more
> {code}



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

[jira] [Resolved] (HBASE-17913) Fix flaky test TestExportSnapshot/TestMobExportSnapshot/TestMobSecureExportSnapshot/TestSecureExportSnapshot

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang resolved HBASE-17913.

Resolution: Duplicate

Duplicate with HBASE-17970.

> Fix flaky test 
> TestExportSnapshot/TestMobExportSnapshot/TestMobSecureExportSnapshot/TestSecureExportSnapshot
> 
>
> Key: HBASE-17913
> URL: https://issues.apache.org/jira/browse/HBASE-17913
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>
> https://builds.apache.org/job/PreCommit-HBASE-Build/6410/artifact/patchprocess/patch-unit-hbase-server.txt
> Failed tests: 
>   TestExportSnapshot.testExportRetry:273->testExportFileSystemState:233 
> expected:<0> but was:<1>
>   
> TestExportSnapshot.testExportWithTargetName:192->testExportFileSystemState:197->testExportFileSystemState:204->testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestMobExportSnapshot>TestExportSnapshot.testExportRetry:273->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestMobExportSnapshot>TestExportSnapshot.testExportWithTargetName:192->TestExportSnapshot.testExportFileSystemState:197->TestExportSnapshot.testExportFileSystemState:204->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestMobSecureExportSnapshot>TestExportSnapshot.testConsecutiveExports:184->TestExportSnapshot.testExportFileSystemState:204->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestMobSecureExportSnapshot>TestExportSnapshot.testEmptyExportFileSystemState:178->TestExportSnapshot.testExportFileSystemState:197->TestExportSnapshot.testExportFileSystemState:204->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestMobSecureExportSnapshot>TestExportSnapshot.testExportFileSystemState:163->TestExportSnapshot.testExportFileSystemState:197->TestExportSnapshot.testExportFileSystemState:204->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestSecureExportSnapshot>TestExportSnapshot.testExportFileSystemStateWithSkipTmp:170->TestExportSnapshot.testExportFileSystemState:197->TestExportSnapshot.testExportFileSystemState:204->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>
>   
> TestSecureExportSnapshot>TestExportSnapshot.testExportRetry:273->TestExportSnapshot.testExportFileSystemState:233
>  expected:<0> but was:<1>



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

[jira] [Resolved] (HBASE-13338) Hbase to use PowerPC supported Jruby version 1.7.20

[Sean Busbey (JIRA)]

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

Sean Busbey resolved HBASE-13338.
-
Resolution: Duplicate

> Hbase to use PowerPC supported Jruby version 1.7.20
> ---
>
> Key: HBASE-13338
> URL: https://issues.apache.org/jira/browse/HBASE-13338
> Project: HBase
>  Issue Type: Task
>  Components: dependencies, shell
>Affects Versions: 1.0.0, 0.98.12
> Environment: PowerPC64, PowerPC64LE
>Reporter: Ayappan
> Attachments: Changes.patch
>
>
> Older versions of jffi (till 1.2.7) don't have native PPC64 & PPC64LE 
> libraries. The latest released 1.2.8 version has PowerPC libraries and the 
> jruby development version(1.7.20--SNAPSHOT) has been updated to make use of 
> this version. Hbase still uses much older jruby 1.6.8 version which don't 
> have the native libraries and this affects the Hbase shell in PowerPCs. So 
> Hbase needs to be updated to make use of the upcoming Jruby release 1.7.20 to 
> support PowerPC.



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

Re: Sporadically failing precommit tasks

[Josh Elser]

(-cc dev@yetus, +bcc dev@yetus)

HBASE-17985 is committed and should do the trick.

Re-trigger QA if you had some JIRA issue blocked on this issue. If 
anyone is still seeing failure, please leave a note on/re-open HBASE-17985.


Thanks!

Josh Elser wrote:

Appears to have done the trick.

https://builds.apache.org/job/PreCommit-HBASE-Build/6671/console

Will open up a new issue just to fix this across the gamut.

Thanks again, all.

Josh Elser wrote:

Thanks, Allen (and Sean).

Let me poke and I'll report back.

Allen Wittenauer wrote:

Hmmm. It's an interesting side-effect of how docker caches
intermediate images:

===

Step 10/35 : RUN apt-get -q update
---> Using cache
---> 79fd4a487c35
Step 11/35 : RUN echo oracle-java7-installer
shared/accepted-oracle-license-v1-1 select true | sudo
/usr/bin/debconf-set-selections
---> Using cache
---> 516879ab5193
Step 12/35 : RUN apt-get -q install -y oracle-java7-installer
---> Using cache
---> c3c88064dbd7
Step 13/35 : RUN echo oracle-java8-installer
shared/accepted-oracle-license-v1-1 select true | sudo
/usr/bin/debconf-set-selections
---> Using cache
---> 98013d157fba
Step 14/35 : RUN apt-get -q install --no-install-recommends -y
oracle-java8-installer

===

Step 10 should probably get merged into Step 12 and Step 14 then
re-arranged a bit. e.g.,

===
RUN echo oracle-java7-installer shared/accepted-oracle-license-v1-1
select true | sudo /usr/bin/debconf-set-selections
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1
select true | sudo /usr/bin/debconf-set-selections
RUN apt-get -q update&& apt-get -q install -y oracle-java7-installer
RUN apt-get -q update&& apt-get -q install --no-install-recommends -y
oracle-java8-installer
===

This would force the update and the image pull to be cached into the
same intermediate.

Although I've been thinking more and more that at least for the
default Yetus Dockerfile, we should probably switch to OpenJDK entirely.

[jira] [Created] (HBASE-17985) Inline package manage updates with package installation in Yetus Dockerfile

[Josh Elser (JIRA)]

Josh Elser created HBASE-17985:
--

 Summary: Inline package manage updates with package installation 
in Yetus Dockerfile
 Key: HBASE-17985
 URL: https://issues.apache.org/jira/browse/HBASE-17985
 Project: HBase
  Issue Type: Bug
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
 Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11


Context: 
https://lists.apache.org/thread.html/d34093557cc510bb8b1dc4b37f8a729b74577c7d4eaecdc3f1badea1@%3Cdev.hbase.apache.org%3E

The way Docker images are built for the Yetus-based PreCommit, we may 
accidentally use a pre-built image that has a stale package-manager cache. If 
the distribution updates their published packages (removing an older version, 
adding a new one), our (stale) client will try to pull the older version which 
is missing, failing.



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

Re: Sporadically failing precommit tasks

[Josh Elser]

Appears to have done the trick.

https://builds.apache.org/job/PreCommit-HBASE-Build/6671/console

Will open up a new issue just to fix this across the gamut.

Thanks again, all.

Josh Elser wrote:

Thanks, Allen (and Sean).

Let me poke and I'll report back.

Allen Wittenauer wrote:

Hmmm. It's an interesting side-effect of how docker caches
intermediate images:

===

Step 10/35 : RUN apt-get -q update
---> Using cache
---> 79fd4a487c35
Step 11/35 : RUN echo oracle-java7-installer
shared/accepted-oracle-license-v1-1 select true | sudo
/usr/bin/debconf-set-selections
---> Using cache
---> 516879ab5193
Step 12/35 : RUN apt-get -q install -y oracle-java7-installer
---> Using cache
---> c3c88064dbd7
Step 13/35 : RUN echo oracle-java8-installer
shared/accepted-oracle-license-v1-1 select true | sudo
/usr/bin/debconf-set-selections
---> Using cache
---> 98013d157fba
Step 14/35 : RUN apt-get -q install --no-install-recommends -y
oracle-java8-installer

===

Step 10 should probably get merged into Step 12 and Step 14 then
re-arranged a bit. e.g.,

===
RUN echo oracle-java7-installer shared/accepted-oracle-license-v1-1
select true | sudo /usr/bin/debconf-set-selections
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1
select true | sudo /usr/bin/debconf-set-selections
RUN apt-get -q update&& apt-get -q install -y oracle-java7-installer
RUN apt-get -q update&& apt-get -q install --no-install-recommends -y
oracle-java8-installer
===

This would force the update and the image pull to be cached into the
same intermediate.

Although I've been thinking more and more that at least for the
default Yetus Dockerfile, we should probably switch to OpenJDK entirely.

Re: Sporadically failing precommit tasks

[Josh Elser]

Thanks, Allen (and Sean).

Let me poke and I'll report back.

Allen Wittenauer wrote:

Hmmm.  It's an interesting side-effect of how docker caches intermediate images:

===

Step 10/35 : RUN apt-get -q update
  --->  Using cache
  --->  79fd4a487c35
Step 11/35 : RUN echo oracle-java7-installer 
shared/accepted-oracle-license-v1-1 select true | sudo 
/usr/bin/debconf-set-selections
  --->  Using cache
  --->  516879ab5193
Step 12/35 : RUN apt-get -q install -y oracle-java7-installer
  --->  Using cache
  --->  c3c88064dbd7
Step 13/35 : RUN echo oracle-java8-installer 
shared/accepted-oracle-license-v1-1 select true | sudo 
/usr/bin/debconf-set-selections
  --->  Using cache
  --->  98013d157fba
Step 14/35 : RUN apt-get -q install --no-install-recommends -y 
oracle-java8-installer

===

Step 10 should probably get merged into Step 12 and Step 14 then re-arranged a 
bit.  e.g.,

===
RUN echo oracle-java7-installer shared/accepted-oracle-license-v1-1 select true 
| sudo /usr/bin/debconf-set-selections
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true 
| sudo /usr/bin/debconf-set-selections
RUN apt-get -q update&&  apt-get -q install -y oracle-java7-installer
RUN apt-get -q update&&  apt-get -q install --no-install-recommends -y 
oracle-java8-installer
===

This would force the update and the image pull to be cached into the same 
intermediate.

Although I've been thinking more and more that at least for the default Yetus 
Dockerfile, we should probably switch to OpenJDK entirely.

Re: Sporadically failing precommit tasks

[Allen Wittenauer]

Hmmm.  It's an interesting side-effect of how docker caches intermediate images:

===

Step 10/35 : RUN apt-get -q update
 ---> Using cache
 ---> 79fd4a487c35
Step 11/35 : RUN echo oracle-java7-installer 
shared/accepted-oracle-license-v1-1 select true | sudo 
/usr/bin/debconf-set-selections
 ---> Using cache
 ---> 516879ab5193
Step 12/35 : RUN apt-get -q install -y oracle-java7-installer
 ---> Using cache
 ---> c3c88064dbd7
Step 13/35 : RUN echo oracle-java8-installer 
shared/accepted-oracle-license-v1-1 select true | sudo 
/usr/bin/debconf-set-selections
 ---> Using cache
 ---> 98013d157fba
Step 14/35 : RUN apt-get -q install --no-install-recommends -y 
oracle-java8-installer

===

Step 10 should probably get merged into Step 12 and Step 14 then re-arranged a 
bit.  e.g.,

===
RUN echo oracle-java7-installer shared/accepted-oracle-license-v1-1 select true 
| sudo /usr/bin/debconf-set-selections
RUN echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true 
| sudo /usr/bin/debconf-set-selections
RUN apt-get -q update && apt-get -q install -y oracle-java7-installer
RUN apt-get -q update && apt-get -q install --no-install-recommends -y 
oracle-java8-installer
===

This would force the update and the image pull to be cached into the same 
intermediate.

Although I've been thinking more and more that at least for the default Yetus 
Dockerfile, we should probably switch to OpenJDK entirely.  

Re: Sporadically failing precommit tasks

[Sean Busbey]

That's my understanding, yes. Note that the dockerfile is per-branch
(we use that to e.g. change our java version IIRC)

On Tue, May 2, 2017 at 11:18 AM, Josh Elser  wrote:
> Thanks, Sean. That sounds like it might help (at least, given the little I
> understand).
>
> Can I just modify dev-support/docker/Dockerfile in my patch and that would
> be picked up?
>
>
> Sean Busbey wrote:
>>
>> +dev@yetus in case some other community has run into this.
>>
>> Yetus is supposed to age out images after a time. Do we know about how
>> long this has been happening?
>>
>> Maybe we could do a get-apt update before the install call?
>>
>> On Tue, May 2, 2017 at 10:41 AM, Josh Elser  wrote:
>>>
>>> I've been running into an issue where the PreCommit job fails when
>>> building
>>> the Yetus Docker image because it attempts to fetch a version of Oracle
>>> JDK8
>>> (8u121) where only a newer version is present (8u131).
>>>
>>> I've seen my tasks [1] fail as well someone else's [2], but I've also
>>> seen
>>> some others [3] [4] which don't appear to have issues. I've not been able
>>> to
>>> determine why some builds run and others don't.
>>>
>>> It seems related to Docker using a cached image that has a "stale"
>>> aptitude
>>> cache, causing apt-get to try to pull the jdk8u121 package instead of the
>>> new jdk8u131 package. I'm not really sure how best to address it though.
>>> Thoughts?
>>>
>>> - Josh
>>>
>>> [1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
>>> [2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
>>> [3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
>>> [4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console
>>
>>
>>
>>
>

Re: Sporadically failing precommit tasks

[Josh Elser]

Aha. That's an interesting point. I missed that the first time :)

Ted Yu wrote:

[3] [4] are for master branch.

Don't know why branch-1 testing is "special".

On Tue, May 2, 2017 at 8:41 AM, Josh Elser  wrote:


I've been running into an issue where the PreCommit job fails when
building the Yetus Docker image because it attempts to fetch a version of
Oracle JDK8 (8u121) where only a newer version is present (8u131).

I've seen my tasks [1] fail as well someone else's [2], but I've also seen
some others [3] [4] which don't appear to have issues. I've not been able
to determine why some builds run and others don't.

It seems related to Docker using a cached image that has a "stale"
aptitude cache, causing apt-get to try to pull the jdk8u121 package instead
of the new jdk8u131 package. I'm not really sure how best to address it
though. Thoughts?

- Josh

[1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
[2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
[3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
[4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console

Re: Sporadically failing precommit tasks

[Josh Elser]

Thanks, Sean. That sounds like it might help (at least, given the little 
I understand).


Can I just modify dev-support/docker/Dockerfile in my patch and that 
would be picked up?


Sean Busbey wrote:

+dev@yetus in case some other community has run into this.

Yetus is supposed to age out images after a time. Do we know about how
long this has been happening?

Maybe we could do a get-apt update before the install call?

On Tue, May 2, 2017 at 10:41 AM, Josh Elser  wrote:

I've been running into an issue where the PreCommit job fails when building
the Yetus Docker image because it attempts to fetch a version of Oracle JDK8
(8u121) where only a newer version is present (8u131).

I've seen my tasks [1] fail as well someone else's [2], but I've also seen
some others [3] [4] which don't appear to have issues. I've not been able to
determine why some builds run and others don't.

It seems related to Docker using a cached image that has a "stale" aptitude
cache, causing apt-get to try to pull the jdk8u121 package instead of the
new jdk8u131 package. I'm not really sure how best to address it though.
Thoughts?

- Josh

[1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
[2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
[3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
[4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console

Re: Sporadically failing precommit tasks

[Ted Yu]

[3] [4] are for master branch.

Don't know why branch-1 testing is "special".

On Tue, May 2, 2017 at 8:41 AM, Josh Elser  wrote:

> I've been running into an issue where the PreCommit job fails when
> building the Yetus Docker image because it attempts to fetch a version of
> Oracle JDK8 (8u121) where only a newer version is present (8u131).
>
> I've seen my tasks [1] fail as well someone else's [2], but I've also seen
> some others [3] [4] which don't appear to have issues. I've not been able
> to determine why some builds run and others don't.
>
> It seems related to Docker using a cached image that has a "stale"
> aptitude cache, causing apt-get to try to pull the jdk8u121 package instead
> of the new jdk8u131 package. I'm not really sure how best to address it
> though. Thoughts?
>
> - Josh
>
> [1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
> [2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
> [3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
> [4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console
>

Re: Sporadically failing precommit tasks

[Sean Busbey]

+dev@yetus in case some other community has run into this.

Yetus is supposed to age out images after a time. Do we know about how
long this has been happening?

Maybe we could do a get-apt update before the install call?

On Tue, May 2, 2017 at 10:41 AM, Josh Elser  wrote:
> I've been running into an issue where the PreCommit job fails when building
> the Yetus Docker image because it attempts to fetch a version of Oracle JDK8
> (8u121) where only a newer version is present (8u131).
>
> I've seen my tasks [1] fail as well someone else's [2], but I've also seen
> some others [3] [4] which don't appear to have issues. I've not been able to
> determine why some builds run and others don't.
>
> It seems related to Docker using a cached image that has a "stale" aptitude
> cache, causing apt-get to try to pull the jdk8u121 package instead of the
> new jdk8u131 package. I'm not really sure how best to address it though.
> Thoughts?
>
> - Josh
>
> [1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
> [2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
> [3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
> [4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console



-- 
Sean

Sporadically failing precommit tasks

[Josh Elser]

I've been running into an issue where the PreCommit job fails when 
building the Yetus Docker image because it attempts to fetch a version 
of Oracle JDK8 (8u121) where only a newer version is present (8u131).


I've seen my tasks [1] fail as well someone else's [2], but I've also 
seen some others [3] [4] which don't appear to have issues. I've not 
been able to determine why some builds run and others don't.


It seems related to Docker using a cached image that has a "stale" 
aptitude cache, causing apt-get to try to pull the jdk8u121 package 
instead of the new jdk8u131 package. I'm not really sure how best to 
address it though. Thoughts?


- Josh

[1] https://builds.apache.org/job/PreCommit-HBASE-Build/6647/console
[2] https://builds.apache.org/job/PreCommit-HBASE-Build/6663/console
[3] https://builds.apache.org/job/PreCommit-HBASE-Build/6664/console
[4] https://builds.apache.org/job/PreCommit-HBASE-Build/6665/console

[jira] [Created] (HBASE-17984) Document guidance on deleting data under %hbase%/.hbck

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-17984:
---

 Summary: Document guidance on deleting data under %hbase%/.hbck
 Key: HBASE-17984
 URL: https://issues.apache.org/jira/browse/HBASE-17984
 Project: HBase
  Issue Type: Improvement
  Components: documentation, hbck
Reporter: Sean Busbey
 Fix For: 2.0.0, 1.5.0


Per user questions on the mailing list, we ought to document things to consider 
when cleaning up data sitting in the {{.hbck}} directory under /hbase.

[reference email thread on 
user@hbase|https://lists.apache.org/thread.html/6c21b5b85378d4a70c3de413c1034c2bfe1a81d71eb73146eb53c9cc@%3Cuser.hbase.apache.org%3E]



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

[jira] [Created] (HBASE-17983) control region numbers when create table to improve performance

[WangYuan (JIRA)]

WangYuan created HBASE-17983:


 Summary: control region numbers when create table to improve 
performance
 Key: HBASE-17983
 URL: https://issues.apache.org/jira/browse/HBASE-17983
 Project: HBase
  Issue Type: Improvement
  Components: Admin, Client
Affects Versions: 2.0.0
Reporter: WangYuan
Priority: Minor
 Fix For: 2.0.0


I found that with the increasing number of regions in every RegionServer , 
HBase read and write performance decreased, and failed to achieve the desired 
performance. Therefore, we hope to control the number of regions in every 
RegionServer , and add the judgment before creating tables.

I can set up a region parameter in hbase-default.xml, 
hbase.client.region.averageload.numbers, when the client builds a table that 
exceeds the value of this parameter, throws an exception.




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

[jira] [Created] (HBASE-17982) Is the word "occured" should be "occurred ?

[Shibin Zhang (JIRA)]

Shibin Zhang created HBASE-17982:


 Summary:  Is the  word "occured" should be "occurred ?
 Key: HBASE-17982
 URL: https://issues.apache.org/jira/browse/HBASE-17982
 Project: HBase
  Issue Type: Bug
Reporter: Shibin Zhang
Priority: Trivial


I have find some spelling may have a problem



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