[jira] [Created] (HBASE-15802) ConnectionUtils should use ThreadLocalRandom instead of Random

[Hiroshi Ikeda (JIRA)]

Hiroshi Ikeda created HBASE-15802:
-

 Summary:  ConnectionUtils should use ThreadLocalRandom instead of 
Random
 Key: HBASE-15802
 URL: https://issues.apache.org/jira/browse/HBASE-15802
 Project: HBase
  Issue Type: Improvement
Reporter: Hiroshi Ikeda
Priority: Minor


{code}
public final class ConnectionUtils {
...skip...
  private static final Random RANDOM = new Random();
{code}

In general, static fields are accessed by multi-threads. The class Random is 
thread-safe but ThreadLocalRandom is more preferable because of less contention.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] First release candidate for HBase 1.1.5 (RC0) is available

[Ted Yu]

Nick:
I was looking at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.5RC0/ but didn't
seem to find the actual .tar.gz files.

Can you double check ?

Thanks

On Sun, May 8, 2016 at 9:23 PM, Nick Dimiduk  wrote:

> *** Please note that my key expired since the previous release. I have
> updated its expiration, pushed to pgp.mit.edu, updated the KEYS file
> linked
> below, and attempted to force an update on id.apache.org. I don't know how
> long it will take for people.apache.org to refresh. ***
>
> *** Please note that this voting window is slightly shorter than the
> customary one week so that we have time for an RC1 before HBaseCon, if
> necessary. ***
>
> I'm happy to announce the first release candidate of HBase 1.1.5 (HBase-1.1
> .5RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.5RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1136/
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory
> https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS file
> http://www-us.apache.org/dist/hbase/KEYS.
>
> There's also a signed tag for this release at
>
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=92323e8e630e46d277ab2e8ebd34b91ab5d597d5
>
> The detailed source and binary compatibility report vs 1.1.4 has been
> published for your review, at
> http://home.apache.org/~ndimiduk/1.1.4_1.1.5RC0_compat_report.html
>
> HBase 1.1.5 is the fifth patch release in the HBase 1.1 line, continuing on
> the theme of bringing a stable, reliable database to the Hadoop and NoSQL
> communities. This release includes over 20 bug fixes since the 1.1.4
> release. Notable correctness fixes
> include HBASE-15234, HBASE-15295, HBASE-15325, HBASE-15622, and
> HBASE-15645.
>
> The full list of fixes included in this release is available at
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753=12335058
> and and in the CHANGES.txt file included in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Thursday, 2016-05-12 as to whether we should release these artifacts as
> HBase 1.1.5.
>
> Thanks,
> Nick
>

Re: [VOTE] First release candidate for HBase 1.1.5 (RC0) is available

[Nick Dimiduk]

- verified tarballs vs public key in KEYS file.
- extracted bin tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone bin tgz with FAST_DIFF block
encoder and ROWCOL blooms. No issues, logs look good.
  - poked around webUI. looks good.
  - verified version in MasterUI matches git tag sha
  - load the site, browsed book and API docs.
- extracted src tgz:
  - inspect structure. look good.
  - run LoadTestTool against standalone built from src tgz with GZ
compression and ROWCOL blooms. No issues, logs look good (modulo the usual
GZ codec spew on this platform).
  - poked around webUI. looks good.
- inspected compatibility report. Nothing to report.

+1

On Sun, May 8, 2016 at 9:23 PM, Nick Dimiduk  wrote:

> *** Please note that my key expired since the previous release. I have
> updated its expiration, pushed to pgp.mit.edu, updated the KEYS file
> linked below, and attempted to force an update on id.apache.org. I don't
> know how long it will take for people.apache.org to refresh. ***
>
> *** Please note that this voting window is slightly shorter than the
> customary one week so that we have time for an RC1 before HBaseCon, if
> necessary. ***
>
> I'm happy to announce the first release candidate of HBase 1.1.5 (HBase-
> 1.1.5RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.5RC0/
>
> Maven artifacts are also available in the staging repository
> https://repository.apache.org/content/repositories/orgapachehbase-1136/
>
> Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
> available in the Apache keys directory
> https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS
> file http://www-us.apache.org/dist/hbase/KEYS.
>
> There's also a signed tag for this release at
> https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=92323e8e630e46d277ab2e8ebd34b91ab5d597d5
>
> The detailed source and binary compatibility report vs 1.1.4 has been
> published for your review, at
> http://home.apache.org/~ndimiduk/1.1.4_1.1.5RC0_compat_report.html
>
> HBase 1.1.5 is the fifth patch release in the HBase 1.1 line, continuing
> on the theme of bringing a stable, reliable database to the Hadoop and
> NoSQL communities. This release includes over 20 bug fixes since the 1.1.4
> release. Notable correctness fixes
> include HBASE-15234, HBASE-15295, HBASE-15325, HBASE-15622, and HBASE-15645.
>
> The full list of fixes included in this release is available at
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753=12335058
> and and in the CHANGES.txt file included in the distribution.
>
> Please try out this candidate and vote +/-1 by 23:59 Pacific time on
> Thursday, 2016-05-12 as to whether we should release these artifacts as
> HBase 1.1.5.
>
> Thanks,
> Nick
>

[VOTE] First release candidate for HBase 1.1.5 (RC0) is available

[Nick Dimiduk]

*** Please note that my key expired since the previous release. I have
updated its expiration, pushed to pgp.mit.edu, updated the KEYS file linked
below, and attempted to force an update on id.apache.org. I don't know how
long it will take for people.apache.org to refresh. ***

*** Please note that this voting window is slightly shorter than the
customary one week so that we have time for an RC1 before HBaseCon, if
necessary. ***

I'm happy to announce the first release candidate of HBase 1.1.5 (HBase-1.1
.5RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.5RC0/

Maven artifacts are also available in the staging repository
https://repository.apache.org/content/repositories/orgapachehbase-1136/

Artifacts are signed with my code signing subkey 0xAD9039071C3489BD,
available in the Apache keys directory
https://people.apache.org/keys/committer/ndimiduk.asc and in our KEYS file
http://www-us.apache.org/dist/hbase/KEYS.

There's also a signed tag for this release at
https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=tag;h=92323e8e630e46d277ab2e8ebd34b91ab5d597d5

The detailed source and binary compatibility report vs 1.1.4 has been
published for your review, at
http://home.apache.org/~ndimiduk/1.1.4_1.1.5RC0_compat_report.html

HBase 1.1.5 is the fifth patch release in the HBase 1.1 line, continuing on
the theme of bringing a stable, reliable database to the Hadoop and NoSQL
communities. This release includes over 20 bug fixes since the 1.1.4
release. Notable correctness fixes
include HBASE-15234, HBASE-15295, HBASE-15325, HBASE-15622, and HBASE-15645.

The full list of fixes included in this release is available at
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310753=12335058
and and in the CHANGES.txt file included in the distribution.

Please try out this candidate and vote +/-1 by 23:59 Pacific time on
Thursday, 2016-05-12 as to whether we should release these artifacts as
HBase 1.1.5.

Thanks,
Nick

Re: What's up with branch-2?

[Nick Dimiduk]

Ah. Did a prune and things are cleared up on my end. Sorry for the noise.

On Sun, May 8, 2016 at 8:44 PM, Matteo Bertozzi 
wrote:

> I can't see it, are you sure you don't have a local copy? (or maybe someone
> deleted it after your mail)
> https://github.com/apache/hbase/commits/branch-2
>
> Matteo
>
>
> On Sun, May 8, 2016 at 6:08 PM, Nick Dimiduk  wrote:
>
> > What's up with this branch-2? Seems like it's back after Sean's
> > HBASE-15006.
> >
>

Re: What's up with branch-2?

[Matteo Bertozzi]

I can't see it, are you sure you don't have a local copy? (or maybe someone
deleted it after your mail)
https://github.com/apache/hbase/commits/branch-2

Matteo


On Sun, May 8, 2016 at 6:08 PM, Nick Dimiduk  wrote:

> What's up with this branch-2? Seems like it's back after Sean's
> HBASE-15006.
>

Re: Write path blocked by MetaDataEndpoint acquiring region lock

[Nick Dimiduk]

Switching from user to dev, user to BCC.

Hi fellas,

I suffered an ingest outage in production this weekend with the symptoms
discussed here; I need to revive this thread.

After speaking a bit offline with Arun, I believe my use of the
ROW_TIMESTAMP feature in combination with a modest total data volume is the
culprit. Prod was unblocked by performing the following actions, though I
must admit I don't know if one of these alone would have been enough:

1. increasing phoenix.stats.guidepost.width to 500mb
2. setting phoenix.stats.useCurrentTime to false
3. dropping all data from SYSTEM.STATS for my user tables

Just as my previous resolution of increasing
phoenix.coprocessor.maxMetaDataCacheSize, I fear these steps are merely
kicking the can down the road. As our user load increases, so too will our
data size and thus more regions and an increasing size of the metadata
cache.

If this is indeed related to user-managed timestamps, as appears to be the
case for both Arun and myself, it means it will also bite users using the
new transactions feature in 4.7. Given the popularity of this new feature,
I believe it's critical we identify a resolution.

I think, as a minimum, we should move the critical section of refreshing
SYSTEM.CATALOG and SYSTEM.STATS out of the regionserver coprocessor
rowlock. Frankly, it's unacceptable to be making RPC calls under such
circumstances. A background thread that refreshes these caches on some
interval is more appropriate. If we require writes be interrupted in order
to accept online schema changes, I propose a ZK watcher/notification as an
alternative design choice.

I'm happy to provide more context, details, logs, jstacks,  as needed.
Looking forward to a timely resolution.

Thanks,
Nick

On Wed, Mar 23, 2016 at 9:20 AM, Thangamani, Arun 
wrote:

> Hey Nick, at least as far as PHOENIX-2607 is concerned, traveling back
> in time to insert data is the fundamental cause of the issue; that is, even
> after we insert the correct data in cache, we ignore whats in the cache
> next time around, and start rebuilding every time. This is by design and
> implementation of timestamps.
> I haven’t had the chance to completely check how UPDATE_CACHE_FREQUENCY
> works yet (James Suggestion) , I am hoping to check that in the next few
> weeks and close out PHOENIX-2607
>
> But in your situation, why are we rebuilding often or not finding meta
> data in cache?, there are few suspects I can think off (from the phoenix
> source code)
> 1) multi tenancy
> 2) guava library version, maybe accidentally a older version is getting
> pulled in at runtime
> 3) client/stat/table timestamp – whatever is getting build for metadata
> cache has timestamp that are different than what we are expecting?
> 4) the cache implementation by itself has a bug getting triggered by your
> use case
>
> I used the same table definition as my prod table, created a local
> instance of phoenix and attached a debugger to see why we needed the
> constant rebuild of meta data.
>
> Sorry, I wish I could help more, but if you can share your table
> definition, I can keep an eye in the next few weeks when I play with
> PHOENIX-2607.
>
> Thanks
> -Arun
>
> From: Nick Dimiduk 
> Date: Friday, March 18, 2016 at 11:32 AM
> To: "u...@phoenix.apache.org" 
> Cc: James Taylor , Lars Hofhansl ,
> "Thangamani, Arun" 
>
> Subject: Re: Write path blocked by MetaDataEndpoint acquiring region lock
>
> Spinning back around here, it seems my configuration change helped, but
> hasn't solved the problem. Jobs are no longer dying from RPC timeouts but I
> still see significant RPC latency spikes associated with SYSTEM.CATALOG.
> Hopefully I can make time to investigate further next week.
>
> @Arun did you gain any more insight into these symptoms on your side?
>
> On Mon, Feb 29, 2016 at 5:03 PM, Nick Dimiduk  wrote:
>
>> Is 1000 a good default?
>>>
>>
>> I'm sure it depends a lot on one's workload.
>>
>> I added some debug logging around the metaDataCache and and acquisition
>> of the rowlock. Checking into the one host with excessive RPC call time, I
>> do indeed see MetaDataEndpointImpl logging cache evictions happening
>> frequently. Looks like the estimatedSize of the stats for one of my tables
>> is pushing 11mb and another table is not far behind. I bumped the value
>> of phoenix.coprocessor.maxMetaDataCacheSize to 100mb, will let that soak
>> for a couple days.
>>
>> Let's get in some extra debug logging folks can enable to see what's
>> going on in there; there's currently no visibility (stats or logging)
>> around this cache. Maybe stats would be better? Better still would be a
>> cache that can dynamically resize to accommodate increasing table (stats)
>> sizes and/or increasing number of tables. I also wonder if it's worth
>> pinning SYSTEM.CATALOG and SYSTEM.STATS to the same 

[jira] [Created] (HBASE-15801) Upgrade checkstyle for all branches

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-15801:
-

 Summary: Upgrade checkstyle for all branches
 Key: HBASE-15801
 URL: https://issues.apache.org/jira/browse/HBASE-15801
 Project: HBase
  Issue Type: Bug
  Components: build
Reporter: Duo Zhang
Assignee: Duo Zhang


We should use the same checkstyle for all branches.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (HBASE-15693) Reconsider the ImportOrder rule of checkstyle

[Nick Dimiduk (JIRA)]

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

Nick Dimiduk reopened HBASE-15693:
--

This is broken on branch-1.1

{noformat}
[INFO] Generating "Checkstyle" report   --- 
maven-checkstyle-plugin:2.13:checkstyle
...
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
hbase: Error generating maven-checkstyle-plugin:2.13:checkstyle: Failed during 
checkstyle configuration: cannot initialize module TreeWalker - Property 
'sortStaticImportsAlphabetically' in module ImportOrder does not exist, please 
check the documentation -> [Help 1]
{noformat}

> Reconsider the ImportOrder rule of checkstyle
> -
>
> Key: HBASE-15693
> URL: https://issues.apache.org/jira/browse/HBASE-15693
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.0.3, 1.1.4, 0.98.19, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>  Labels: checkstyle
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.1.5, 1.2.2, 0.98.20
>
> Attachments: HBASE-15693-0.98.patch, HBASE-15693-branch-1.0.patch, 
> HBASE-15693-branch-1.1.patch, HBASE-15693-branch-1.2.patch, 
> HBASE-15693-branch-1.3.patch, HBASE-15693-branch-1.patch, HBASE-15693.patch
>
>
> I have been confused many times with the wrong import order checkstyle 
> warnings in the pre commit result. And I haven't found any developer guide 
> which tells me what is the right order so this time I decided to read the 
> rule by myself.
> In the ImportOrder section, we declare sortStaticImportsAlphabetically which 
> can only work with option 'top' or 'bottom'(which means place static imports 
> on top or bottom) and use the default option which is 'under'.
> I prefer placing static import on top, so I suggest here we set option to 
> 'top'.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15800) check_compatibility.sh no longer works with rel/YYY tags

[Nick Dimiduk (JIRA)]

Nick Dimiduk created HBASE-15800:


 Summary: check_compatibility.sh no longer works with rel/YYY tags
 Key: HBASE-15800
 URL: https://issues.apache.org/jira/browse/HBASE-15800
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.0
Reporter: Nick Dimiduk
Priority: Minor


Previously (recently as 2 weeks ago) it was possible to use the 
{{dev-support/check_compatibility.sh}} script against the tags under {{rel}}. 
Now ({{5e0}}) this is no longer the case. On a mac,

{noformat}
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home
$ GETOPT=/usr/local/Cellar/gnu-getopt/1.1.6/bin/getopt 
./dev-support/check_compatibility.sh -r 
https://git-wip-us.apache.org/repos/asf/hbase.git rel/1.1.4 branch-1.1
...
Running the Java API Compliance Checker...
ERROR: can't access 
'./dev-support/target/compatibility/1/hbase-annotations/target/hbase-annotations-1.1.4.jar,./dev-support/target/compatibility/1/hbase-checkstyle/target/hbase-checkstyle-1.1.
4.jar,./dev-support/target/compatibility/1/hbase-client/target/hbase-client-1.1.4.jar,./dev-support/target/compatibility/1/hbase-common/target/hbase-common-1.1.4.jar,./dev-support/target/compat
ibility/1/hbase-examples/target/hbase-examples-1.1.4.jar,./dev-support/target/compatibility/1/hbase-hadoop-compat/target/hbase-hadoop-compat-1.1.4.jar,./dev-support/target/compatibility/1/hbase
-hadoop2-compat/target/hbase-hadoop2-compat-1.1.4.jar,./dev-support/target/compatibility/1/hbase-it/target/hbase-it-1.1.4.jar,./dev-support/target/compatibility/1/hbase-prefix-tree/target/hbase
-prefix-tree-1.1.4.jar,./dev-support/target/compatibility/1/hbase-procedure/target/hbase-procedure-1.1.4.jar,./dev-support/target/compatibility/1/hbase-protocol/target/hbase-protocol-1.1.4.jar,
./dev-support/target/compatibility/1/hbase-resource-bundle/target/hbase-resource-bundle-1.1.4.jar,./dev-support/target/compatibility/1/hbase-rest/target/hbase-rest-1.1.4.jar,./dev-support/targe
t/compatibility/1/hbase-server/target/hbase-server-1.1.4.jar,./dev-support/target/compatibility/1/hbase-shell/target/hbase-shell-1.1.4.jar,./dev-support/target/compatibility/1/hbase-testing-uti
l/target/hbase-testing-util-1.1.4.jar,./dev-support/target/compatibility/1/hbase-thrift/target/hbase-thrift-1.1.4.jar'
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

What's up with branch-2?

[Nick Dimiduk]

What's up with this branch-2? Seems like it's back after Sean's HBASE-15006.

[jira] [Created] (HBASE-15799) Two Shell 'close_region' Example Syntaxes Don't Work

[Matt Warhaftig (JIRA)]

Matt Warhaftig created HBASE-15799:
--

 Summary: Two Shell 'close_region' Example Syntaxes Don't Work
 Key: HBASE-15799
 URL: https://issues.apache.org/jira/browse/HBASE-15799
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 2.0.0
Reporter: Matt Warhaftig
Assignee: Matt Warhaftig
Priority: Minor


The close_region shell command's help message lists the following usage 
syntaxes:

{noformat}
hbase> close_region 'REGIONNAME'
hbase> close_region 'REGIONNAME', 'SERVER_NAME'
hbase> close_region 'ENCODED_REGIONNAME'
hbase> close_region 'ENCODED_REGIONNAME', 'SERVER_NAME'
{noformat}

admin.rb's current code (with close_region method being the entry point) is:
{code}
def close_region(region_name, server)
  if (server == nil || !closeEncodedRegion?(region_name, server))
@admin.closeRegion(region_name, server)
  end
end

def closeEncodedRegion?(region_name, server)
   @admin.closeRegionWithEncodedRegionName(region_name, server)
end
{code}

The {{close_region 'ENCODED_REGIONNAME'}} syntax currently will not work 
because when server = nil the {{closeEncodedRegion}} method call is skipped.

The {{close_region 'REGIONNAME', 'SERVER_NAME'}} syntax currently will not work 
because {{@admin.closeRegionWithEncodedRegionName}} throws an 
NotServingRegionException (for the non-encoded region_name) that is uncaught in 
and prevents execution from returning to {{close_region}} and the correct call 
of {{HBaseAdmin.closeRegion}}. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Successful: HBase Generate Website

[Apache Jenkins Server]

Build status: Successful

If successful, the website and docs have been generated. If failed, skip to the 
bottom of this email.

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

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

  cd hbase-site
  wget -O- 
https://builds.apache.org/job/hbase_generate_website/223/artifact/website.patch.zip
 | funzip > 9ee0cbb995c1d7de905f4138a199f115762725e8.patch
  git fetch
  git checkout -b asf-site-9ee0cbb995c1d7de905f4138a199f115762725e8 
origin/asf-site
  git am --whitespace=fix 9ee0cbb995c1d7de905f4138a199f115762725e8.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-9ee0cbb995c1d7de905f4138a199f115762725e8 branch, and you can review 
the differences by running:

  git diff origin/asf-site

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

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

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

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

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

  git push origin asf-site-9ee0cbb995c1d7de905f4138a199f115762725e8:asf-site

Changes take a couple of minutes to be propagated. You can then remove your 
asf-site-9ee0cbb995c1d7de905f4138a199f115762725e8 branch:

  git checkout asf-site && git branch -d 
asf-site-9ee0cbb995c1d7de905f4138a199f115762725e8



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

[jira] [Resolved] (HBASE-15746) RegionCoprocessor preClose() called 3 times

[Matteo Bertozzi (JIRA)]

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

Matteo Bertozzi resolved HBASE-15746.
-
Resolution: Duplicate

> RegionCoprocessor preClose() called 3 times
> ---
>
> Key: HBASE-15746
> URL: https://issues.apache.org/jira/browse/HBASE-15746
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, regionserver
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 0.98.19
>Reporter: Matteo Bertozzi
>Priority: Minor
>
> The preClose() region coprocessor call gets called 3 times via rpc.
> The first one is when we receive the RPC
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L1329
> The second time is when ask the RS to close the region
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L2852
> The third time is when the doClose() on the region is executed.
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L1419
> I'm pretty sure the first one can be removed since, there is no code between 
> that and the second call. and they are a copy-paste.
> The second one explicitly says that is to enforce ACLs before starting the 
> operation, which leads me to the fact that the 3rd one in the region gets 
> executed too late in the process. but the region.close() may be called by 
> someone other than the RS, so we should probably leave the preClose() in 
> there (e.g. OpenRegionHandler on failure cleanup). 
> any idea?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15798) Add Async RpcChannels to all RpcClients

[Jurriaan Mous (JIRA)]

Jurriaan Mous created HBASE-15798:
-

 Summary: Add Async RpcChannels to all RpcClients
 Key: HBASE-15798
 URL: https://issues.apache.org/jira/browse/HBASE-15798
 Project: HBase
  Issue Type: Bug
Reporter: Jurriaan Mous
Assignee: Jurriaan Mous


The RpcClients all need to expose an async protobuf RpcChannel and our own 
custom AsyncRpcChannel (without protobuf overhead) so an Async table 
implementation can be made.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15797) TestIPCUtil fails after HBASE-15795

[Jurriaan Mous (JIRA)]

Jurriaan Mous created HBASE-15797:
-

 Summary: TestIPCUtil fails after HBASE-15795
 Key: HBASE-15797
 URL: https://issues.apache.org/jira/browse/HBASE-15797
 Project: HBase
  Issue Type: Bug
Reporter: Jurriaan Mous
Assignee: Jurriaan Mous


Seems an output stream is not closed after the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)