[jira] [Resolved] (HBASE-19919) Tidying up logging

[stack (JIRA)]

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

stack resolved HBASE-19919.
---
   Resolution: Fixed
 Assignee: stack
Fix Version/s: 2.0.0-beta-2

Pushed to branch-2 and master.

> Tidying up logging
> --
>
> Key: HBASE-19919
> URL: https://issues.apache.org/jira/browse/HBASE-19919
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.0-beta-2
>
> Attachments: 0001-HBASE-19919-Tidying-up-logging.patch, 
> HBASE-19919.branch-2.001.patch
>
>
> Reading logs, there is a bunch of stuff we don't need, thread names are too 
> long, etc. Doing a little tidying.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

HBaseCon Plans?

[Mike Drob]

Hi folks, has there been any consideration put forth toward the next
HBaseCon? The last one was very productive for me personally, but I hadn't
heard anything about the schedule for 2018 so figured I could ask on list.

Mike

Re: Is HBaseTestingUtility part of public API?

[Apekshit Sharma]

bq. Anything in test/ can't be public API by definition. Move it into src/
if that is desired.

If that has always been our stance, we should probably clarify it in our
documentation. Or maybe it's already there and i missed it.
Didn't find anything searching for 'test' in
http://hbase.apache.org/book.html#hbase.versioning.

I see IA.Public annotations on follow classes under **/test/ path:
HBCommonTU, HBTU, MiniHBaseCluster, CodecPerformance, and
HBaseZKTestingUtility

At least MiniHBaseCluster seems like it might be useful to downstream
projects. Others may have nuggets which might make sense in public api.
Not sure what's best though - moving the classes + declaration that test/
code is private, or letting annotations do they work as they do work src/
code.

-- Appy


On Fri, Feb 2, 2018 at 5:56 PM, Andrew Purtell  wrote:

> Phoenix is being a bit naughty. On the other hand, the status of this class
> isn't clear.
>
> On Fri, Jan 26, 2018 at 2:10 PM, Ted Yu  wrote:
>
> > At least Phoenix is using it.
> > If you search in Phoenix repo, you would see a lot of classes with:
> >
> > import org.apache.hadoop.hbase.HBaseTestingUtility;
> >
> > If you have specific method(s) which you consider changing, you can ask
> > dev@phoenix.
> >
> > FYI
> >
> > On Fri, Jan 26, 2018 at 2:01 PM, Mike Drob  wrote:
> >
> > > Can we make changes between releases? Do we know who else is using it?
> > >
> > > Mike
> > >
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>



-- 

-- Appy

[jira] [Created] (HBASE-19925) Delete an unreachable peer will triggers all regionservers abort

[Yun Zhao (JIRA)]

Yun Zhao created HBASE-19925:


 Summary: Delete an unreachable peer will triggers all 
regionservers abort
 Key: HBASE-19925
 URL: https://issues.apache.org/jira/browse/HBASE-19925
 Project: HBase
  Issue Type: Bug
Reporter: Yun Zhao


Add an unreachable peer
{code:java}
add_peer '4', CLUSTER_KEY => "server1.cie.com:2181:/hbase"{code}
After a while to delete it,Regionserver will appear in the following log and 
stop.
{code:java}
2018-02-02 20:04:25,959 INFO [main-EventThread.replicationSource,4] 
regionserver.ReplicationSource: Replicating 
5467de52-dc46-45be-902c-110dd7a83e06 -> null
2018-02-02 20:04:25,960 ERROR 
[main-EventThread.replicationSource,4.replicationSource..com%2C16020%2C1515498473547.default,4]
 regionserver.ReplicationSource: Unexpected exception in 
ReplicationSourceWorkerThread, currentPath=null
java.lang.IllegalArgumentException: Peer with id= 4 is not connected
 at 
org.apache.hadoop.hbase.replication.ReplicationPeersZKImpl.getStatusOfPeer(ReplicationPeersZKImpl.java:207)
 at 
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.isPeerEnabled(ReplicationSource.java:327)
 at 
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource$ReplicationSourceWorkerThread.run(ReplicationSource.java:512)
2018-02-02 20:04:25,960 INFO 
[main-EventThread.replicationSource,4.replicationSource..com%2C16020%2C1515498473547.default,4]
 regionserver.HRegionServer: STOPPED: Unexpected exception in 
ReplicationSourceWorkerThread{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-19924) hbase rpc throttling does not work for multi() with request count rater.

[huaxiang sun (JIRA)]

huaxiang sun created HBASE-19924:


 Summary: hbase rpc throttling does not work for multi() with 
request count rater.
 Key: HBASE-19924
 URL: https://issues.apache.org/jira/browse/HBASE-19924
 Project: HBase
  Issue Type: Bug
  Components: rpc
Affects Versions: 1.2.6, 2.0
Reporter: huaxiang sun
Assignee: huaxiang sun


Basically, rpc throttling does not work for request count based rater for 
multi. for the following code, when it calls limiter's checkQuota(), 
numWrites/numReads is lost.
{code:java}

@Override
public void checkQuota(int numWrites, int numReads, int numScans) throws 
ThrottlingException {
  writeConsumed = estimateConsume(OperationType.MUTATE, numWrites, 100);
  readConsumed = estimateConsume(OperationType.GET, numReads, 100);
  readConsumed += estimateConsume(OperationType.SCAN, numScans, 1000);

  writeAvailable = Long.MAX_VALUE;
  readAvailable = Long.MAX_VALUE;
  for (final QuotaLimiter limiter : limiters) {
if (limiter.isBypass()) continue;

limiter.checkQuota(writeConsumed, readConsumed);
readAvailable = Math.min(readAvailable, limiter.getReadAvailable());
writeAvailable = Math.min(writeAvailable, limiter.getWriteAvailable());
  }

  for (final QuotaLimiter limiter : limiters) {
limiter.grabQuota(writeConsumed, readConsumed);
  }
}{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Is HBaseTestingUtility part of public API?

[Andrew Purtell]

Phoenix is being a bit naughty. On the other hand, the status of this class
isn't clear.

On Fri, Jan 26, 2018 at 2:10 PM, Ted Yu  wrote:

> At least Phoenix is using it.
> If you search in Phoenix repo, you would see a lot of classes with:
>
> import org.apache.hadoop.hbase.HBaseTestingUtility;
>
> If you have specific method(s) which you consider changing, you can ask
> dev@phoenix.
>
> FYI
>
> On Fri, Jan 26, 2018 at 2:01 PM, Mike Drob  wrote:
>
> > Can we make changes between releases? Do we know who else is using it?
> >
> > Mike
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Is HBaseTestingUtility part of public API?

[Andrew Purtell]

Anything in test/ can't be public API by definition. Move it into src/ if
that is desired.

On Fri, Jan 26, 2018 at 2:01 PM, Mike Drob  wrote:

> Can we make changes between releases? Do we know who else is using it?
>
> Mike
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

[jira] [Created] (HBASE-19923) Reset peer state and config when refresh replication source failed

[Guanghao Zhang (JIRA)]

Guanghao Zhang created HBASE-19923:
--

 Summary: Reset peer state and config when refresh replication 
source failed
 Key: HBASE-19923
 URL: https://issues.apache.org/jira/browse/HBASE-19923
 Project: HBase
  Issue Type: Bug
Reporter: Guanghao Zhang


Now we use procedure for replication. When peer state changed, the RS will read 
peer state from storage to cache. If RS found the peer state changed, then it 
will refresh replication source. If refresh failed, the Master will retry the 
procedure. Then RS will read peer state again, but now the peer state in cache 
is right. So it don't refresh replication source.. So we need reset the 
peer state to old peer state when refresh failed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Considering branching for 1.5 and other branch-1 release planning

[Andrew Purtell]

> What are the gate criteria on moving the stable pointer?

We were waiting on feedback from Mikhail or Gary. Last I heard was it was
fine over there, except one use case would trigger occasional regionserver
aborts due to FNFE in storefile handling. HBASE-19728 is the latest to fix
issues around storefile locking. These are getting harder to find, so the
answer as to the stability of 1.3 is it is getting better, and might be
good enough. Someone needs to step forward and make a credible claim to
that effect. Where I work we are rolling out something based on 1.3. It is
a heavy lift because most of our production is still on 0.98 and there are
some nontrivial differences. We are making progress. Once we have been
stable at a high scale location for several months I'll write in to claim
it stable. If someone else is using 1.3 your feedback would be very
valuable. In our acceptance testing 1.3 survived tests where 1.1 and 1.2
fell over, for what it's worth.

> You've been putting in a lot of hours into release duties already,
Andrew, let's hope that somebody else is available

I'm sure someone can step in if need be. Thanks for volunteering to run a
release, though. Any time you'd like to do that I'll be happy to help you
run through it if you need assistance. make_rc.sh mostly automates the
process. I think all committers who have an interest in running a release
should do it. It's good experience doing the one activity more than just
about any other that moves the project forward. However I don't mind being
RM. I enjoy it. I missed it after retiring 0.98. Getting 2.0 out is super
important. I can keep the legacy code branches in good order with steady
releases in the meantime.


On Fri, Feb 2, 2018 at 4:28 PM, Mike Drob  wrote:

> What are the gate criteria on moving the stable pointer?
>
> IIRC there was intent to do another 1.2.x release where Sean passed the
> reigns (Appy, still interested?)
>
> You've been putting in a lot of hours into release duties already, Andrew,
> let's hope that somebody else is available.
> If it can wait until March, I might be able to pick it up to take load off
> of you. Otherwise, I'll keep plodding along on the 2.0 work.
>
> Mike
>
> On Fri, Feb 2, 2018 at 5:48 PM, Andrew Purtell 
> wrote:
>
> > Also, the next expected release for branch-1.4, 1.4.2, will be proposed
> at
> > the end of March.
> >
> > On Fri, Feb 2, 2018 at 3:28 PM, Andrew Purtell 
> > wrote:
> >
> > > The backport of RSGroups to branch-1 triggered the opening of the 1.4
> > code
> > > line as branch-1.4 and releases 1.4.0 and 1.4.1.
> > >
> > > After the commit of HBASE-19858 (Backport HBASE-14061 (Support CF-level
> > > Storage Policy) to branch-1), storage policy aware file placement might
> > be
> > > useful enough to trigger a new minor release from branch-1. This would
> be
> > > branch-1.5, and at least release 1.5.0. I am not sure about this yet.
> It
> > > needs testing. I'd like to mock up a couple of use cases and determine
> if
> > > what we have is sufficient on its own or more changes will be needed. I
> > > want to get the idea of a 1.5 on your radar. though.
> > >
> > > Also, I would like to make one more release of branch-1.3 before we
> > retire
> > > it. Mikhail passed the reins. We might have a volunteer to RM 1.3.2. If
> > > not, I will do it. I'm expecting 1.4 will supersede 1.3 but this will
> be
> > > decided organically depending on uptake.
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Considering branching for 1.5 and other branch-1 release planning

[Mike Drob]

What are the gate criteria on moving the stable pointer?

IIRC there was intent to do another 1.2.x release where Sean passed the
reigns (Appy, still interested?)

You've been putting in a lot of hours into release duties already, Andrew,
let's hope that somebody else is available.
If it can wait until March, I might be able to pick it up to take load off
of you. Otherwise, I'll keep plodding along on the 2.0 work.

Mike

On Fri, Feb 2, 2018 at 5:48 PM, Andrew Purtell  wrote:

> Also, the next expected release for branch-1.4, 1.4.2, will be proposed at
> the end of March.
>
> On Fri, Feb 2, 2018 at 3:28 PM, Andrew Purtell 
> wrote:
>
> > The backport of RSGroups to branch-1 triggered the opening of the 1.4
> code
> > line as branch-1.4 and releases 1.4.0 and 1.4.1.
> >
> > After the commit of HBASE-19858 (Backport HBASE-14061 (Support CF-level
> > Storage Policy) to branch-1), storage policy aware file placement might
> be
> > useful enough to trigger a new minor release from branch-1. This would be
> > branch-1.5, and at least release 1.5.0. I am not sure about this yet. It
> > needs testing. I'd like to mock up a couple of use cases and determine if
> > what we have is sufficient on its own or more changes will be needed. I
> > want to get the idea of a 1.5 on your radar. though.
> >
> > Also, I would like to make one more release of branch-1.3 before we
> retire
> > it. Mikhail passed the reins. We might have a volunteer to RM 1.3.2. If
> > not, I will do it. I'm expecting 1.4 will supersede 1.3 but this will be
> > decided organically depending on uptake.
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: Considering branching for 1.5 and other branch-1 release planning

[Andrew Purtell]

Also, the next expected release for branch-1.4, 1.4.2, will be proposed at
the end of March.

On Fri, Feb 2, 2018 at 3:28 PM, Andrew Purtell  wrote:

> The backport of RSGroups to branch-1 triggered the opening of the 1.4 code
> line as branch-1.4 and releases 1.4.0 and 1.4.1.
>
> After the commit of HBASE-19858 (Backport HBASE-14061 (Support CF-level
> Storage Policy) to branch-1), storage policy aware file placement might be
> useful enough to trigger a new minor release from branch-1. This would be
> branch-1.5, and at least release 1.5.0. I am not sure about this yet. It
> needs testing. I'd like to mock up a couple of use cases and determine if
> what we have is sufficient on its own or more changes will be needed. I
> want to get the idea of a 1.5 on your radar. though.
>
> Also, I would like to make one more release of branch-1.3 before we retire
> it. Mikhail passed the reins. We might have a volunteer to RM 1.3.2. If
> not, I will do it. I'm expecting 1.4 will supersede 1.3 but this will be
> decided organically depending on uptake.
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Anonymous survey: Apache HBase 1.x Usage

[Andrew Purtell]

Please take this anonymous survey
​ to ​
let us know what version of Apache HBase 1.x you are using in production
now or are planning to use in production in the next year or so.

Multiple choices are allowed.

​There is no "I'm not using 1.x" choice. Consider upgrading! (smile)

https://www.surveymonkey.com/r/8WQ8QY6


-- 
Best regards,
Andrew

Considering branching for 1.5 and other branch-1 release planning

[Andrew Purtell]

The backport of RSGroups to branch-1 triggered the opening of the 1.4 code
line as branch-1.4 and releases 1.4.0 and 1.4.1.

After the commit of HBASE-19858 (Backport HBASE-14061 (Support CF-level
Storage Policy) to branch-1), storage policy aware file placement might be
useful enough to trigger a new minor release from branch-1. This would be
branch-1.5, and at least release 1.5.0. I am not sure about this yet. It
needs testing. I'd like to mock up a couple of use cases and determine if
what we have is sufficient on its own or more changes will be needed. I
want to get the idea of a 1.5 on your radar. though.

Also, I would like to make one more release of branch-1.3 before we retire
it. Mikhail passed the reins. We might have a volunteer to RM 1.3.2. If
not, I will do it. I'm expecting 1.4 will supersede 1.3 but this will be
decided organically depending on uptake.

-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

[RESULT] [VOTE] The first HBase 1.4.1 release candidate (RC0) is available

[Andrew Purtell]

​+1


​
With 8 nonbinding +1s, 3 binding +1s, and no 0 or -1 votes, this vote
passes.

Thanks to all who voted on the release! Much appreciated!


On Thu, Feb 1, 2018 at 3:13 PM, Ted Yu  wrote:

> +1
>
> Ran test suite with Java 1.8 - passed
> Checked signature
> Ran LTT with 1M row - passed
> Checked basic WebUI
> Exercised shell commands
>
> On Tue, Jan 30, 2018 at 1:11 PM, Andrew Purtell 
> wrote:
>
> > You should follow the build instructions on our online manual (look for
> > the #maven.release anchor). Please file a JIRA and maybe someone suitably
> > motivated will look at it but I dont see this as a veto-able concern
> unless
> > the build fails following our release procedures. That didn't happen. Or
> > we'd not have a release candidate. :-)
> >
> >
> > > On Jan 30, 2018, at 1:00 PM, Zach York 
> > wrote:
> > >
> > > -0 (non-binding)
> > >
> > > It still looks like mvn clean site fails (Also fails for 1.4.0, hence
> > not a
> > > -1):
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> > > project hbase: Error generating maven-javadoc-plugin:2.10.3:aggregate:
> > > [ERROR] Exit code: 1 - warning: unknown enum constant When.MAYBE
> > > [ERROR] reason: class file for javax.annotation.meta.When not found
> > > [ERROR] warning: unknown enum constant When.ALWAYS
> > > [ERROR] warning: unknown enum constant When.UNKNOWN
> > > [ERROR] javadoc: error -
> > > com.sun.tools.doclets.internal.toolkit.util.DocletAbortException:
> > > com.sun.tools.javac.code.Symbol$CompletionFailure: class file for
> > > javax.annotation.concurrent.Immutable not found
> > >
> > > There was some initial investigation/discussion in
> > > https://issues.apache.org/jira/browse/HBASE-19663 and
> > > https://issues.apache.org/jira/browse/HBASE-19780 but that was for
> > branch-2.
> > > Probably not a blocker for the release, but I still wanted to call this
> > out.
> > >
> > > Zach
> > >
> > >
> > >
> > >> On Tue, Jan 30, 2018 at 4:26 AM, Yu Li  wrote:
> > >>
> > >> +1
> > >>
> > >> Checked sums and signatures: ok
> > >> Built from source: ok (7u79)
> > >> RAT check: ok (7u79)
> > >> Compatibility check: ok (7u79)
> > >> Unit tests pass: ok (7u79)
> > >> Shell commands: ok (8u101), ran DDL/flush/compact/split commands,
> > >> everything looks good
> > >> Loaded 1M rows with LTT: ok (8u101), all keys verified, latency and
> logs
> > >> looks good
> > >>
> > >> Best Regards,
> > >> Yu
> > >>
> > >>> On 30 January 2018 at 02:28, Andrew Purtell 
> > wrote:
> > >>>
> > >>> Thanks Peter, much appreciated.
> > >>>
> > >>> On Mon, Jan 29, 2018 at 9:35 AM, Peter Somogyi <
> psomo...@cloudera.com>
> > >>> wrote:
> > >>>
> >  The tests failed in localhost mode when executed from maven. I've
> just
> >  checked some integration tests now on 1.4.0 and it fails there as
> > well,
> > >>> so
> >  it not a regression. I'm OK with a +1 on this RC.
> > 
> >  Peter
> > 
> >  On Mon, Jan 29, 2018 at 5:52 PM, Andrew Purtell <
> > >>> andrew.purt...@gmail.com>
> >  wrote:
> > 
> > > Are the integration test failures from when it runs in localhost
> > >> mode?
> > >>> I
> > > think these are long term test issues present since 1.3. Or, is
> this
> > >>> new
> >  in
> > > 1.4.1? If these also have the same result with 1.4.0, indicating no
> > >> new
> > > regression, would you consider changing your vote?
> > >
> > >> On Jan 29, 2018, at 6:54 AM, Peter Somogyi  >
> > > wrote:
> > >>
> > >> 0
> > >>
> > >> - RAT check: OK
> > >> - Signatures, checksums: OK
> > >> - Build from src: OK
> > >> - Start standalone from src and bin, run shell commands: OK
> > >> - LTT 1M rows: OK
> > >> - Web UI, logs: OK
> > >> - Ran full test suite: passes except integration tests
> > >>
> > >> I had failures in IntegrationTestRpcClient, IntegrationTestMTTR,
> > >> IntegrationTestBigLinkedListWithVisibility and
> > >> IntegrationTestWithCellVisibilityLoadAndVerify. All other tests
> > >>> passed
> > > for
> > >> me.
> > >>
> > >>> On Thu, Jan 25, 2018 at 3:45 AM, Andrew Purtell <
> > >>> apurt...@apache.org>
> > > wrote:
> > >>>
> > >>> The first HBase 1.4.1 release candidate (RC0) is available for
> >  download
> > > at
> > >>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/ and
> >  Maven
> > >>> artifacts are available in the temporary repository
> > >>> https://repository.apache.org/content/repositories/
> >  orgapachehbase-1194
> > > .
> > >>>
> > >>> The git tag corresponding to the candidate is '1.4.1RC0'
> > >>> (4b25debc83).
> > >>>
> > >>> A detailed source and binary compatibility report for this
> release
> > >>> is
> > >>> available for your review at
> > >>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.4.1RC0/
> > >>> compat-check-report.html
> > >>> .
> > >>

[jira] [Created] (HBASE-19922) ProtobufUtils::PRIMITIVES is unused

[Mike Drob (JIRA)]

Mike Drob created HBASE-19922:
-

 Summary: ProtobufUtils::PRIMITIVES is unused
 Key: HBASE-19922
 URL: https://issues.apache.org/jira/browse/HBASE-19922
 Project: HBase
  Issue Type: Task
  Components: Protobufs
Reporter: Mike Drob


It looks like ProtobufUtils::PRIMITIVES is never read in both the shaded and 
non-shaded versions of the class. Is it safe to remove?

https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java#L128

We populate the map in a static initializer but never read any values from it...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Flaky dashboard is flaky

[Apekshit Sharma]

Someone, jenkins process on GCP instance (that IP) died.
Removed it from flaky list for now (to unblock building fresh dashboards).
I have restarted the jenkins process, and will add it back later once
dash-building job goes green again.
Thanks for bringing it up Balazs.

-- Appy

On Fri, Feb 2, 2018 at 5:13 AM, Balazs Meszaros <
balazs.mesza...@cloudera.com> wrote:

> Hi,
>
> The Flaky Dashboard for HBase 2.0 was not updated in the past few days
> (last successful run was at 31 January). Last build
> 
> failed because of a networking problem:
>
> requests.exceptions.ConnectionError:
> HTTPConnectionPool(host='104.198.223.121', port=8080): Max retries
> exceeded with url: /job/HBase-Flaky-Tests-branch2.0//api/json (Caused
> by : [Errno 111] Connection refused)
>
> I can access the dashboard.html file of the last build, but according to
> the last updated field value it was updated at *01/31/2018 00:16:19*.
>
> It is also the same for master flaky dashboard.
>
> Could anybody check it?
>
> Thanks,
> Balazs
>



-- 

-- Appy

[jira] [Resolved] (HBASE-19921) Disable 1.1 nightly builds.

[stack (JIRA)]

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

stack resolved HBASE-19921.
---
   Resolution: Fixed
 Assignee: stack
Fix Version/s: 1.1.13
 Release Note: Disabled nightly build on branch-1.1 since it EOL'd.

Removed JenkinsFile from under dev-support. Pushed to branch-1.1.



> Disable 1.1 nightly builds.
> ---
>
> Key: HBASE-19921
> URL: https://issues.apache.org/jira/browse/HBASE-19921
> Project: HBase
>  Issue Type: Sub-task
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 1.1.13
>
> Attachments: 0001-HBASE-19921-Disable-1.1-nightly-builds.patch
>
>
> As suggested by [~mdrob], remove the JenkinsFile is the trick (Nightlies run 
> for all branches in hbase).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-19921) Disable 1.1 nightly builds.

[stack (JIRA)]

stack created HBASE-19921:
-

 Summary: Disable 1.1 nightly builds.
 Key: HBASE-19921
 URL: https://issues.apache.org/jira/browse/HBASE-19921
 Project: HBase
  Issue Type: Sub-task
Reporter: stack


As suggested by [~mdrob], remove the JenkinsFile is the trick (Nightlies run 
for all branches in hbase).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-19920) TokenUtil.obtainToken unnecessarily creates a local directory

[Rohini Palaniswamy (JIRA)]

Rohini Palaniswamy created HBASE-19920:
--

 Summary: TokenUtil.obtainToken unnecessarily creates a local 
directory
 Key: HBASE-19920
 URL: https://issues.apache.org/jira/browse/HBASE-19920
 Project: HBase
  Issue Type: Bug
Reporter: Rohini Palaniswamy


On client code, when one calls TokenUtil.obtainToken it loads ProtobufUtil 
which in its static block initializes DynamicClassLoader and that creates the 
directory ${hbase.rootdir}/lib

https://github.com/apache/hbase/blob/master/hbase-common/src/main/java/org/apache/hadoop/hbase/util/DynamicClassLoader.java#L115-L127

Since this is region server specific code, not expecting this to happen when 
one accesses hbase as a client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Flaky dashboard is flaky

[Balazs Meszaros]

Hi,

The Flaky Dashboard for HBase 2.0 was not updated in the past few days
(last successful run was at 31 January). Last build

failed because of a networking problem:

requests.exceptions.ConnectionError:
HTTPConnectionPool(host='104.198.223.121', port=8080): Max retries
exceeded with url: /job/HBase-Flaky-Tests-branch2.0//api/json (Caused
by : [Errno 111] Connection refused)

I can access the dashboard.html file of the last build, but according to
the last updated field value it was updated at *01/31/2018 00:16:19*.

It is also the same for master flaky dashboard.

Could anybody check it?

Thanks,
Balazs

[jira] [Created] (HBASE-19919) Tidying up logging

[stack (JIRA)]

stack created HBASE-19919:
-

 Summary: Tidying up logging
 Key: HBASE-19919
 URL: https://issues.apache.org/jira/browse/HBASE-19919
 Project: HBase
  Issue Type: Bug
Reporter: stack






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)