[jira] [Created] (HBASE-17733) Undo registering regionservers in zk with ephemeral nodes; its more trouble than its worth

[stack (JIRA)]

stack created HBASE-17733:
-

 Summary: Undo registering regionservers in zk with ephemeral 
nodes; its more trouble than its worth
 Key: HBASE-17733
 URL: https://issues.apache.org/jira/browse/HBASE-17733
 Project: HBase
  Issue Type: Brainstorming
Reporter: stack


Elsewhere, we are undoing the use of ZK (replication current WAL offset, 
regions-in-transition, etc).

I have another case where using ZK, while convenient (call-backs), has holes.

The scenario is prompted by review of HBASE-9593.

Currently, a RS registers with the Master by calling the Master's 
reportForDuty. After the Master responds with the name we are to use for 
ourselves (as well as other properties we need to 'run'), we then turnaround 
and do a new RPC out to the zk ensemble to register an ephemeral znode for the 
RS.

We notice a RS has gone away -- crashed -- because its znode evaporates and the 
Master has a watcher triggered notifying it the RS has gone (after a zk session 
timeout of tens of seconds).  Cumbersome (Setting watchers, zk session 
timeouts) and indirect. Master then trips the server shutdown handler which 
does reassign of regions from the crashed server.

In HBASE-9593, we were trying to handle the rare but possible case where the RS 
would die after registering w/ the Master but before we put up our ephemeral 
znode. In this case a RS would live in the Master's internals forever because 
there is no ephemeral znode to expire to do cleanup and removal of the 
never-started RS.

Lets get ZK out of the loop. Then only the Master and RS involved heartbeating 
each other.



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

[jira] [Resolved] (HBASE-16630) Fragmentation in long running Bucket Cache

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan resolved HBASE-16630.

Resolution: Fixed

Pushed to all branches including branch-1.2. There was an env issue in my 
branch-1.2. I was able to correct that and committed this patch. 
Thanks for all the reviews and for your persistence with this patch [~dvdreddy].

> Fragmentation in long running Bucket Cache
> --
>
> Key: HBASE-16630
> URL: https://issues.apache.org/jira/browse/HBASE-16630
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.0.0, 1.1.6, 1.3.1, 1.2.3
>Reporter: deepankar
>Assignee: deepankar
>Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.6
>
> Attachments: 16630-v2-suggest.patch, 16630-v3-suggest.patch, 
> HBASE-16630.patch, HBASE-16630-v2.patch, HBASE-16630-v3-branch-1.patch, 
> HBASE-16630-v3-branch-1.X.patch, HBASE-16630-v3.patch, 
> HBASE-16630-v4-branch-1.X.patch
>
>
> As we are running bucket cache for a long time in our system, we are 
> observing cases where some nodes after some time does not fully utilize the 
> bucket cache, in some cases it is even worse in the sense they get stuck at a 
> value < 0.25 % of the bucket cache (DEFAULT_MEMORY_FACTOR as all our tables 
> are configured in-memory for simplicity sake).
> We took a heap dump and analyzed what is happening and saw that is classic 
> case of fragmentation, current implementation of BucketCache (mainly 
> BucketAllocator) relies on the logic that fullyFreeBuckets are available for 
> switching/adjusting cache usage between different bucketSizes . But once a 
> compaction / bulkload happens and the blocks are evicted from a bucket size , 
> these are usually evicted from random places of the buckets of a bucketSize 
> and thus locking the number of buckets associated with a bucketSize and in 
> the worst case of the fragmentation we have seen some bucketSizes with 
> occupancy ratio of <  10 % But they dont have any completelyFreeBuckets to 
> share with the other bucketSize. 
> Currently the existing eviction logic helps in the cases where cache used is 
> more the MEMORY_FACTOR or MULTI_FACTOR and once those evictions are also 
> done, the eviction (freeSpace function) will not evict anything and the cache 
> utilization will be stuck at that value without any allocations for other 
> required sizes.
> The fix for this we came up with is simple that we do deFragmentation ( 
> compaction) of the bucketSize and thus increasing the occupancy ratio and 
> also freeing up the buckets to be fullyFree, this logic itself is not 
> complicated as the bucketAllocator takes care of packing the blocks in the 
> buckets, we need evict and re-allocate the blocks for all the BucketSizes 
> that dont fit the criteria.
> I am attaching an initial patch just to give an idea of what we are thinking 
> and I'll improve it based on the comments from the community.



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

Re: hbase-default.xml seems to be for an older version of HBase

[Ted Yu]

w.r.t. mixed path separators, were you referring to:

mkdir -p "$outputDirectory/org/apache/hadoop/hbase"
cat >"$outputDirectory/org/apache/hadoop/hbase/Version.java" < wrote:

> The issue is the mixed path separators being passed to the script
> saveVersion.sh
>
> I recompiled on Ubuntu and everything is fine now.
>
> So the take away is that the exec step can fail however maven reports
> build successful.
>
> thanks
>
> 
> From: jeff saremi 
> Sent: Friday, March 3, 2017 6:47:05 PM
> To: dev@hbase.apache.org
> Subject: hbase-default.xml seems to be for an older version of HBase
>
>
> I get this baffling error message after doing a compilation of Hbase
> rel/1.2.2 (on Windows/Mingw) and running it on a windows server.
>
> Looking at the source, hbase-default.xml is in the hbase-common project
> and I verified it to be included in the runtime jar file.
>
> I cannot say anything about the contents of this file since it seems to be
> filled with references and place holders. I am attaching it as extracted
> from the hbase-common-1.2.2jar.
>
> Thanks
>
>
> Exception in thread "main" java.lang.RuntimeException: hbase-default.xml
> file seems to be for an older version of HBase (1.2.2), this version is
> Unknown
> at org.apache.hadoop.hbase.HBaseConfiguration.
> checkDefaultsVersion(HBaseConfiguration.java:71)
> at org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(
> HBaseConfiguration.java:81)
> at org.apache.hadoop.hbase.HBaseConfiguration.create(
> HBaseConfiguration.java:96)
> at org.apache.hadoop.hbase.regionserver.HRegionServer.
> main(HRegionServer.java:2660)
>
>

Re: hbase-default.xml seems to be for an older version of HBase

[jeff saremi]

The issue is the mixed path separators being passed to the script saveVersion.sh

I recompiled on Ubuntu and everything is fine now.

So the take away is that the exec step can fail however maven reports build 
successful.

thanks


From: jeff saremi 
Sent: Friday, March 3, 2017 6:47:05 PM
To: dev@hbase.apache.org
Subject: hbase-default.xml seems to be for an older version of HBase


I get this baffling error message after doing a compilation of Hbase rel/1.2.2 
(on Windows/Mingw) and running it on a windows server.

Looking at the source, hbase-default.xml is in the hbase-common project and I 
verified it to be included in the runtime jar file.

I cannot say anything about the contents of this file since it seems to be 
filled with references and place holders. I am attaching it as extracted from 
the hbase-common-1.2.2jar.

Thanks


Exception in thread "main" java.lang.RuntimeException: hbase-default.xml file 
seems to be for an older version of HBase (1.2.2), this version is Unknown
at 
org.apache.hadoop.hbase.HBaseConfiguration.checkDefaultsVersion(HBaseConfiguration.java:71)
at 
org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(HBaseConfiguration.java:81)
at 
org.apache.hadoop.hbase.HBaseConfiguration.create(HBaseConfiguration.java:96)
at 
org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:2660)

Re: hbase-default.xml seems to be for an older version of HBase

[jeff saremi]

I'm looking further into this.

I started the mvn package in the hbase-common folder and just relaized that an 
exec error got silently skipped. I bet this is where the version info is saved 
into a class:


[INFO] --- maven-antrun-plugin:1.6:run (generate) @ hbase-common ---
[INFO] Executing tasks

main:
 [exec] Error: 0x80070057
 [exec]
 [exec] Result: -1
...

[INFO] Building jar: D:\repos\hbase\hbase-common\target\hbase-common-1.2.2.jar
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 9.589 s
[INFO] Finished at: 2017-03-03T19:07:14-08:00
[INFO] Final Memory: 41M/764M



I'll check further and report back.


From: jeff saremi 
Sent: Friday, March 3, 2017 6:47:05 PM
To: dev@hbase.apache.org
Subject: hbase-default.xml seems to be for an older version of HBase


I get this baffling error message after doing a compilation of Hbase rel/1.2.2 
(on Windows/Mingw) and running it on a windows server.

Looking at the source, hbase-default.xml is in the hbase-common project and I 
verified it to be included in the runtime jar file.

I cannot say anything about the contents of this file since it seems to be 
filled with references and place holders. I am attaching it as extracted from 
the hbase-common-1.2.2jar.

Thanks


Exception in thread "main" java.lang.RuntimeException: hbase-default.xml file 
seems to be for an older version of HBase (1.2.2), this version is Unknown
at 
org.apache.hadoop.hbase.HBaseConfiguration.checkDefaultsVersion(HBaseConfiguration.java:71)
at 
org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(HBaseConfiguration.java:81)
at 
org.apache.hadoop.hbase.HBaseConfiguration.create(HBaseConfiguration.java:96)
at 
org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:2660)

hbase-default.xml seems to be for an older version of HBase

[jeff saremi]

I get this baffling error message after doing a compilation of Hbase rel/1.2.2 
(on Windows/Mingw) and running it on a windows server.

Looking at the source, hbase-default.xml is in the hbase-common project and I 
verified it to be included in the runtime jar file.

I cannot say anything about the contents of this file since it seems to be 
filled with references and place holders. I am attaching it as extracted from 
the hbase-common-1.2.2jar.

Thanks


Exception in thread "main" java.lang.RuntimeException: hbase-default.xml file 
seems to be for an older version of HBase (1.2.2), this version is Unknown
at 
org.apache.hadoop.hbase.HBaseConfiguration.checkDefaultsVersion(HBaseConfiguration.java:71)
at 
org.apache.hadoop.hbase.HBaseConfiguration.addHbaseResources(HBaseConfiguration.java:81)
at 
org.apache.hadoop.hbase.HBaseConfiguration.create(HBaseConfiguration.java:96)
at 
org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:2660)








  
  
hbase.tmp.dir
${java.io.tmpdir}/hbase-${user.name}
Temporary directory on the local filesystem.
Change this setting to point to a location more permanent
than '/tmp', the usual resolve for java.io.tmpdir, as the
'/tmp' directory is cleared on machine restart.
  
  
hbase.rootdir
${hbase.tmp.dir}/hbase
The directory shared by region servers and into
which HBase persists.  The URL should be 'fully-qualified'
to include the filesystem scheme.  For example, to specify the
HDFS directory '/hbase' where the HDFS instance's namenode is
running at namenode.example.org on port 9000, set this value to:
hdfs://namenode.example.org:9000/hbase.  By default, we write
to whatever ${hbase.tmp.dir} is set too -- usually /tmp --
so change this configuration or else all data will be lost on
machine restart.
  
  
hbase.fs.tmp.dir
/user/${user.name}/hbase-staging
A staging directory in default file system (HDFS)
for keeping temporary data.

  
  
hbase.bulkload.staging.dir
${hbase.fs.tmp.dir}
A staging directory in default file system (HDFS)
for bulk loading.

  
  
hbase.cluster.distributed
false
The mode the cluster will be in. Possible values are
  false for standalone mode and true for distributed mode.  If
  false, startup will run all HBase and ZooKeeper daemons together
  in the one JVM.
  
  
hbase.zookeeper.quorum
localhost
Comma separated list of servers in the ZooKeeper ensemble
(This config. should have been named hbase.zookeeper.ensemble).
For example, "host1.mydomain.com,host2.mydomain.com,host3.mydomain.com".
By default this is set to localhost for local and pseudo-distributed modes
of operation. For a fully-distributed setup, this should be set to a full
list of ZooKeeper ensemble servers. If HBASE_MANAGES_ZK is set in hbase-env.sh
this is the list of servers which hbase will start/stop ZooKeeper on as
part of cluster start/stop.  Client-side, we will take this list of
ensemble members and put it together with the hbase.zookeeper.clientPort
config. and pass it into zookeeper constructor as the connectString
parameter.
  
  

  
hbase.local.dir
${hbase.tmp.dir}/local/
Directory on the local filesystem to be used
as a local storage.
  

  
  
hbase.master.port
16000
The port the HBase Master should bind to.
  
  
hbase.master.info.port
16010
The port for the HBase Master web UI.
Set to -1 if you do not want a UI instance run.
  
  
hbase.master.info.bindAddress
0.0.0.0
The bind address for the HBase Master web UI

  
  
hbase.master.logcleaner.plugins
org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner
A comma-separated list of BaseLogCleanerDelegate invoked by
the LogsCleaner service. These WAL cleaners are called in order,
so put the cleaner that prunes the most files in front. To
implement your own BaseLogCleanerDelegate, just put it in HBase's classpath
and add the fully qualified class name here. Always add the above
default log cleaners in the list.
  
  
hbase.master.logcleaner.ttl
60
Maximum time a WAL can stay in the .oldlogdir directory,
after which it will be cleaned by a Master thread.
  
  
hbase.master.hfilecleaner.plugins
org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner
A comma-separated list of BaseHFileCleanerDelegate invoked by
the HFileCleaner service. These HFiles cleaners are called in order,
so put the cleaner that prunes the most files in front. To
implement your own BaseHFileCleanerDelegate, just put it in HBase's classpath
and add the fully qualified class name here. Always add the above
default log cleaners in the list as they will be overwritten in
hbase-site.xml.
  
  
hbase.master.catalog.timeout
60
Timeout value for the 

[jira] [Created] (HBASE-17732) Add CpType template to CoprocessorEnvironment

[Appy (JIRA)]

Appy created HBASE-17732:


 Summary: Add CpType template to CoprocessorEnvironment
 Key: HBASE-17732
 URL: https://issues.apache.org/jira/browse/HBASE-17732
 Project: HBase
  Issue Type: Improvement
Reporter: Appy
Assignee: Appy


Adding template for coprocessor type to CoprocessorEnvironment will:
- get rid of 'instanceOf' checks we do in various coprocessor hosts
- allow us to load only relevant coprocessors in hosts (right now i think each 
host loads all coprocs and it's only during execOperation that it checks if the 
coproc is of correct type ie XXCoprocessorHost will load XXObserver, 
YYObserver, and all others, and in will check in execOperation if coproc is of 
type XXObserver and ignore the rest).
- allow sharing of a bunch functions/classes which are currently 99% duplicate 
of each other. For eg. CoprocessorOperations, CoprocessorOperationWithResult, 
execOperations().



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

[jira] [Created] (HBASE-17731) Fractional latency reporting in MultiThreadedAction

[Andrew Purtell (JIRA)]

Andrew Purtell created HBASE-17731:
--

 Summary: Fractional latency reporting in MultiThreadedAction
 Key: HBASE-17731
 URL: https://issues.apache.org/jira/browse/HBASE-17731
 Project: HBase
  Issue Type: Improvement
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Trivial
 Fix For: 2.0.0, 1.4.0, 1.3.1
 Attachments: HBASE-17731.patch

When average latency is less than one millisecond the LoadTestTool tool reports 
a latency of 0. Better to report a fraction out to a couple of decimal points. 




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

[jira] [Created] (HBASE-17730) Migration to 2.0 for coprocessors

[Appy (JIRA)]

Appy created HBASE-17730:


 Summary: Migration to 2.0 for coprocessors 
 Key: HBASE-17730
 URL: https://issues.apache.org/jira/browse/HBASE-17730
 Project: HBase
  Issue Type: Sub-task
Reporter: Appy


Jiras breaking coprocessor compatibility should be marked with component ' 
Coprocessor', and label 'incompatible'.
Close to releasing 2.0, we should go through all such jiras and write down 
steps for migrating coprocessor easily.
The idea is, it might be very hard to fix coprocessor breakages by reverse 
engineering errors,  but will be easier we suggest easiest way to fix breakages 
resulting from each individual incompatible change.

For eg. HBASE-17312 is incompatible change. It'll result in 100s of errors 
because BaseXXXObserver classes are gone, but the fix is actually just one line 
: simply change "Foo extends BaseXXXObserver" to "Foo implements XXXObserver".



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

[jira] [Created] (HBASE-17729) Missing shortcuts for some useful HCD options

[Andrew Purtell (JIRA)]

Andrew Purtell created HBASE-17729:
--

 Summary: Missing shortcuts for some useful HCD options
 Key: HBASE-17729
 URL: https://issues.apache.org/jira/browse/HBASE-17729
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 1.3.0
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Trivial
 Fix For: 2.0.0, 1.4.0, 1.3.1


Missing:
- CACHE_INDEX_ON_WRITE 
- CACHE_BLOOMS_ON_WRITE
- EVICT_BLOCKS_ON_CLOSE
- CACHE_DATA_IN_L1

It's possible to set them with syntax like 
{noformat}
{ CONFIGURATION = {  =  } }
{noformat}
but let's save some keystrokes. 



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

[jira] [Created] (HBASE-17728) Separate Configuration into common module

[Ted Yu (JIRA)]

Ted Yu created HBASE-17728:
--

 Summary: Separate Configuration into common module
 Key: HBASE-17728
 URL: https://issues.apache.org/jira/browse/HBASE-17728
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: Ted Yu


User is in security module.
When User::isSecurityEnabled() is added, we need to query Configuration for 
security setting.
However, this introduces a circular build dependency:

BUILD FAILED: Cycle found: //connection:connection -> //security:security -> 
//core:core -> //connection:connection

This issue is to separate Configuration into common module which is depended 
upon by both core and connection modules.



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

[jira] [Created] (HBASE-17727) [C++] Make RespConverter work with MockRawAsyncTableImpl

[Xiaobing Zhou (JIRA)]

Xiaobing Zhou created HBASE-17727:
-

 Summary: [C++] Make RespConverter work with MockRawAsyncTableImpl
 Key: HBASE-17727
 URL: https://issues.apache.org/jira/browse/HBASE-17727
 Project: HBase
  Issue Type: Sub-task
Reporter: Xiaobing Zhou
Assignee: Xiaobing Zhou


This is a follow up work of HBASE-17465. 

There's a problem to dereference instance of RpcCallback when it's passed as 
function argument.

{code}
template
using RespConverter = std::function;
{code}

{code}
  template
  folly::Future Call(
  std::shared_ptr rpc_client,
  std::shared_ptr controller,
  std::shared_ptr loc,
  const REQ& req,
  const ReqConverter& 
req_converter,
  const hbase::RpcCall& rpc_call,
  const RespConverter& resp_converter) {
rpc_call(
rpc_client,
loc,
controller,
std::move(req_converter(req, loc->region_name(
.then([&, this](std::unique_ptr presp) {
  // std::unique_ptr result = resp_converter(presp);
  std::unique_ptr result = 
hbase::ResponseConverter::FromGetResponse(*presp);
  promise_->setValue(std::move(*result));
})
.onError([this] (const std::exception& e) {promise_->setException(e);});
return promise_->getFuture();
  }
{code}



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

[jira] [Created] (HBASE-17726) [C++] Move implementation from header to cc for request retry

[Xiaobing Zhou (JIRA)]

Xiaobing Zhou created HBASE-17726:
-

 Summary: [C++] Move implementation from header to cc for request 
retry
 Key: HBASE-17726
 URL: https://issues.apache.org/jira/browse/HBASE-17726
 Project: HBase
  Issue Type: Sub-task
Reporter: Xiaobing Zhou
Assignee: Xiaobing Zhou


This is a follow up work related to HBASE-17465.



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

[jira] [Created] (HBASE-17725) LimitedPrivate COPROC / PHOENIX interface broken on maintenance release

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-17725:
---

 Summary: LimitedPrivate COPROC / PHOENIX interface broken on 
maintenance release
 Key: HBASE-17725
 URL: https://issues.apache.org/jira/browse/HBASE-17725
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 1.1.8, 1.2.5
Reporter: Sean Busbey
Priority: Blocker
 Fix For: 1.2.5


The compatibility report for HBase 1.2.5 RC0 flagged one item, the interface 
{{RpcServiceInterface}} added a new method {{setRsRpcServices}}. That interface 
is labeled {{IA.LimitedPrivate(COPROC, PHOENIX)}}.

AFAICT this change came in on HBASE-16972. There's discussion on that ticket 
about the compatibility impact of the change in logging on earlier releases 
(which I remain fine with). The only discussion about binary/source 
compatibility expressly changes a different part of the patch to avoid breaking 
coprocessors and phoenix.

As an extra wrinkle, this change has already been published in the 1.1.z 
release line for 1.1.8 and 1.1.9. Apologies, but I haven't gone to verify there 
wasn't a discussion of this break when 1.1.8 came out.




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

[jira] [Created] (HBASE-17724) Include a list of all metrics in the refguide

[stack (JIRA)]

stack created HBASE-17724:
-

 Summary: Include a list of all metrics in the refguide
 Key: HBASE-17724
 URL: https://issues.apache.org/jira/browse/HBASE-17724
 Project: HBase
  Issue Type: Improvement
  Components: documentation
Reporter: stack


It keeps coming up that we are missing a list of all metrics in our 
documentation.

How could we get full list? Metrics are published on JMX. A jsp page scrapes 
our published mbeans to draw a json dump of metrics when you browse to /jmx. 
JMX is the source of truth regards the complete set published. How to go from 
jmx to a page in the refguide?

Seems like you have to start up an instance just to query it. Could be done as 
part of the book build or as preamble to the book build. So, we could scrape 
jmx mbeans or /jmx json dump. But then we'd have to get it into a form asciidoc 
could digest. Haven't dug in. Let me make this a beginner issue.



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

Re: Need guidance on getting detailed elapsed times in every stage of processing a request

[Sean Busbey]

-user@hbase to bcc
+dev@hbase

Jeff,

These kinds of questions get into things that we only handle within
the development community. I've copied in the appropriate dev@hbase
mailing list, please ensure you are subscribed there so you can see
any further discussion.

On Fri, Mar 3, 2017 at 1:13 PM, jeff saremi  wrote:
> Yu
> Of the patches attached to HBASE-15160, do I need to apply all (v2, v3, ...) 
> or just  HBASE-15160.patch ?
> Also how would I know against what version this patch was created?
> thanks
>
>
>
>
> 
> From: jeff saremi 
> Sent: Friday, March 3, 2017 10:34:00 AM
> To: Hbase-User
> Subject: Re: Need guidance on getting detailed elapsed times in every stage 
> of processing a request
>
> Thanks a lot Yu
>
> These are truly the metrics we care about about at this point. It is sad to 
> see that such important metrics were removed from the code.
>
> I will try to apply your patch on my own to the version of HBase we have. We 
> definitely need these.
>
> Other solutions like HTrace are not as urgent as having these few metrics you 
> talked about here. So if we can get these merged with the code we should be 
> happy.
>
>
> 
> From: Yu Li 
> Sent: Friday, March 3, 2017 9:54:29 AM
> To: Hbase-User
> Subject: Re: Need guidance on getting detailed elapsed times in every stage 
> of processing a request
>
> Hi Jeff,
>
> If the question is simply monitoring HDFS read/write latencies, please
> refer to HBASE-15160 ,
> there's a patch but not committed yet, and probably cannot apply cleanly on
> current code base, but still some good reference IMHO, so JFYI.
>
> To get an overview of how quickly the system could respond and what might
> be the root cause of the spikes, we only need to monitor the
> average/p99/p999 latency of below metrics (stages):
> 1. totalCallTime: time from request arriving at server to sending response
> 2. processCallTime: time for the server to process the call, regardless of
> the time this call being queued
> 3. queueCallTime: time the call has been queued
> 4. HDFS read/pread/write time: time of HFile reading/writing, added in
> HBASE-15160
> 5. WAL sync time: time of WAL sync to HDFS, critical path of writing request
>
> However, for your original question, that to monitor the whole trace of a
> single request, I'm afraid no mature solution for the time being just as
> Stack mentioned.
>
> Hope my answer helps (smile).
>
> Best Regards,
> Yu
>
> On 4 March 2017 at 00:48, jeff saremi  wrote:
>
>> anything would help. thanks
>>
>> 
>> From: saint@gmail.com  on behalf of Stack <
>> st...@duboce.net>
>> Sent: Thursday, March 2, 2017 9:53:41 PM
>> To: Hbase-User
>> Subject: Re: Need guidance on getting detailed elapsed times in every
>> stage of processing a request
>>
>> On Thu, Mar 2, 2017 at 10:26 PM, jeff saremi 
>> wrote:
>>
>> > So i'd like to come back to my original question on how to get about
>> > separating the latency of HDFS from HBase.
>> >
>> >
>> That is a simple question to which we do not have an answer unfortunately
>> (we should). If interested, I could describe how you might do it. I don't
>> think it would take much work.
>>
>> St.Ack
>>
>>
>>
>> > Is there a most appropriate log4j TRACE option that could print out this
>> > information to the logs?
>> > Thanks
>> >
>> > 
>> > From: jeff saremi 
>> > Sent: Thursday, March 2, 2017 12:45:59 PM
>> > To: Hbase-User
>> > Subject: Re: Need guidance on getting detailed elapsed times in every
>> > stage of processing a request
>> >
>> > Thanks so much for the advice! Looking forward to when Tracing gets
>> picked
>> > up again
>> >
>> > 
>> > From: saint@gmail.com  on behalf of Stack <
>> > st...@duboce.net>
>> > Sent: Thursday, March 2, 2017 12:17:35 PM
>> > To: Hbase-User
>> > Subject: Re: Need guidance on getting detailed elapsed times in every
>> > stage of processing a request
>> >
>> > HBase/HTrace integration once worked but has long since rotted.
>> > Refactorings of internals without proper respect for trace connections is
>> > the main culprit. Updates in htrace and hdfs that need attention
>> > reconnecting spans, etc., is another. On top of this, zipkin project has
>> > seen a burst of effort of late that would seem to offer much promise if
>> > someone of us spent some time rejiggering how HTrace and Zipkin relate.
>> >
>> > I would not waste any time on trying to setup HTrace for HBase at least
>> > until after HBASE-14451 goes in, an issue that has been put aside with a
>> > while now. Sorry if you've burned time on this to date.
>> >
>> > Yours,
>> > St.Ack
>> >
>> > On Thu, Mar 2, 2017 at 6:28 AM, jeff 

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. To update the live 
site, follow the instructions below. If failed, skip to the bottom of this 
email.

Use the following commands to download the patch and apply it to a clean branch 
based on origin/asf-site. If you prefer to keep the hbase-site repo around 
permanently, you can skip the clone step.

  git clone https://git-wip-us.apache.org/repos/asf/hbase-site.git

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/505/artifact/website.patch.zip
 | funzip > 678ad0ea73812a7b2d4f48d2569f8736fd827200.patch
  git fetch
  git checkout -b asf-site-678ad0ea73812a7b2d4f48d2569f8736fd827200 
origin/asf-site
  git am --whitespace=fix 678ad0ea73812a7b2d4f48d2569f8736fd827200.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-678ad0ea73812a7b2d4f48d2569f8736fd827200 branch.

There are lots of spurious changes, such as timestamps and CSS styles in 
tables, so a generic git diff is not very useful. To see a list of files that 
have been added, deleted, renamed, changed type, or are otherwise interesting, 
use the following command:

  git diff --name-status --diff-filter=ADCRTXUB origin/asf-site

To see only files that had 100 or more lines changed:

  git diff --stat origin/asf-site | grep -E '[1-9][0-9]{2,}'

When you are satisfied, publish your changes to origin/asf-site using these 
commands:

  git commit --allow-empty -m "Empty commit" # to work around a current ASF 
INFRA bug
  git push origin asf-site-678ad0ea73812a7b2d4f48d2569f8736fd827200:asf-site
  git checkout asf-site
  git branch -D asf-site-678ad0ea73812a7b2d4f48d2569f8736fd827200

Changes take a couple of minutes to be propagated. You can verify whether they 
have been propagated by looking at the Last Published date at the bottom of 
http://hbase.apache.org/. It should match the date in the index.html on the 
asf-site branch in Git.

As a courtesy- reply-all to this email to let other committers know you pushed 
the site.



If failed, see https://builds.apache.org/job/hbase_generate_website/505/console

[jira] [Created] (HBASE-17723) TestServerSideScanMetricsFromClientSide and TestRecoveredEdits fail

[Anup Halarnkar (JIRA)]

Anup Halarnkar created HBASE-17723:
--

 Summary: TestServerSideScanMetricsFromClientSide and 
TestRecoveredEdits fail
 Key: HBASE-17723
 URL: https://issues.apache.org/jira/browse/HBASE-17723
 Project: HBase
  Issue Type: Bug
  Components: integration tests
Affects Versions: 2.0.0
 Environment: Ubuntu 14.04 LTS / x86_64 / 16GB RAM
Reporter: Anup Halarnkar


Command to build and test:
mvn clean install -X 
JAVA_TOOL_OPTIONS: -Xmx4G -XX:MaxPermSize=4G -Xms1G

Failure in tests:
Results :

Failed tests:
  
TestServerSideScanMetricsFromClientSide.testRowsSeenMetricWithAsync:161->testRowsSeenMetric:174->testRowsSeenMetric:204->testMetric:330
 Metric: ROWS_SCANNED Expected: 9 Actual: 8 expected:<9> but was:<8>
  
TestRecoveredEdits.testReplayWorksThoughLotsOfFlushing:78->testReplayWorksWithMemoryCompactionPolicy:149->verifyAllEditsMadeItIn:195
 Failed to find 
W\xE1X\xDBv\xD8}\x07\xBF\xC1I\xF1\xF5\xB9\x84\xD8/meta:prev/1422491946444/Put/vlen=16/seqid=0

Tests run: 1761, Failures: 2, Errors: 0, Skipped: 6


This is the output for 1st test failure:
---
Test set: org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.971 sec <<< 
FAILURE! - in org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide
testRowsSeenMetricWithAsync(org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide)
  Time elapsed: 1.134 sec  <<< FAILURE!
java.lang.AssertionError: Metric: ROWS_SCANNED Expected: 9 Actual: 8 
expected:<9> but was:<8>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide.testMetric(TestServerSideScanMetricsFromClientSide.java:330)
at 
org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide.testRowsSeenMetric(TestServerSideScanMetricsFromClientSide.java:204)
at 
org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide.testRowsSeenMetric(TestServerSideScanMetricsFromClientSide.java:174)
at 
org.apache.hadoop.hbase.TestServerSideScanMetricsFromClientSide.testRowsSeenMetricWithAsync(TestServerSideScanMetricsFromClientSide.java:161)


This is output of 2nd test failure:
---
Test set: org.apache.hadoop.hbase.regionserver.TestRecoveredEdits
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.911 sec <<< 
FAILURE! - in org.apache.hadoop.hbase.regionserver.TestRecoveredEdits
testReplayWorksThoughLotsOfFlushing(org.apache.hadoop.hbase.regionserver.TestRecoveredEdits)
  Time elapsed: 11.871 sec  <<< FAILURE!
java.lang.AssertionError: Failed to find 
W\xE1X\xDBv\xD8}\x07\xBF\xC1I\xF1\xF5\xB9\x84\xD8/meta:prev/1422491946444/Put/vlen=16/seqid=0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.hadoop.hbase.regionserver.TestRecoveredEdits.verifyAllEditsMadeItIn(TestRecoveredEdits.java:195)
at 
org.apache.hadoop.hbase.regionserver.TestRecoveredEdits.testReplayWorksWithMemoryCompactionPolicy(TestRecoveredEdits.java:149)
at 
org.apache.hadoop.hbase.regionserver.TestRecoveredEdits.testReplayWorksThoughLotsOfFlushing(TestRecoveredEdits.java:78)


Please let me know if you need more information

Thanks,
Anup





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