Re: One problem about document change

2017-07-17 Thread Guanghao Zhang
Thanks for your explanation. So if we only push it to master branch, we
should only add master tag to the fix versions of the document issue, right?

2017-07-17 22:00 GMT+08:00 Sean Busbey :

> Contributors and committers usually only worry about making documentation
> changes to the master branch.
>
> When it comes time to spin up release candidates for a new version, the
> release manager usually copies the then-current state of documentation in
> the master branch to the branch they'll be working from (in this case
> branch-2). Sometimes that documentation is also tailored further to the
> release line (e.g. to remove irrelevant feature discussion).
>
> On Sun, Jul 16, 2017 at 9:16 AM, Guanghao Zhang 
> wrote:
>
> > Hi, folks
> >
> > Now I am working on the asynchronous admin which is part of asynchronous
> > client. The asynchronous client feature were pushed to branch-2 and
> master
> > branch. But one confuse thing is about the document change. The book site
> > is generated by master branch's code. So the document change should only
> be
> > pushed to master branch? Or it should be pushed to branch-2 and master
> > both, because this feature was merged to branch-2, too? I am not sure
> about
> > this, so look forward to you guys' idea. Thanks.
> >
> > Guanghao Zhang
> >
>


[jira] [Created] (HBASE-18401) Region Replica broken in branch-1

2017-07-17 Thread huaxiang sun (JIRA)
huaxiang sun created HBASE-18401:


 Summary: Region Replica broken in branch-1
 Key: HBASE-18401
 URL: https://issues.apache.org/jira/browse/HBASE-18401
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.2.6, 1.3.1
Reporter: huaxiang sun
Assignee: huaxiang sun


Read replica is broken in branch-1, after the region split, we saw replica 
region as content in hbase:meta, while the previous behavior is that replica 
region should not show up in info:regioninfo.

{code}
t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 column=info:regioninfo, 
timestamp=1500340472406, value={ENCODED => d8faa669dde775c323f6e55fd5aa36e0, 
NAME => 't1,r2111,1500340472229_0001.d8faa669dde7
 e73ca. 75c323f6e55fd5aa36e0.', 
STARTKEY => 'r2111', ENDKEY => 'r2', REPLICA_ID => 1}   
  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 
column=info:seqnumDuringOpen, timestamp=1500340472379, 
value=\x00\x00\x00\x00\x00\x00\x00\x02  
   
 e73ca. 

  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 
column=info:seqnumDuringOpen_0001, timestamp=1500340472406, 
value=\x00\x00\x00\x00\x00\x00\x00\x02  
  
 e73ca. 

  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 column=info:server, 
timestamp=1500340472379, value=dhcp-172-16-1-203.pa.cloudera.com:59105  
  
 e73ca. 

  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 column=info:server_0001, 
timestamp=1500340472406, value=dhcp-172-16-1-203.pa.cloudera.com:59105  
 
 e73ca. 

  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 
column=info:serverstartcode, timestamp=1500340472379, value=1500340443589   
  
 e73ca. 

  
 t1,r2111,1500340472229.814f68c2d6e92dd8acb82a55706 
column=info:serverstartcode_0001, timestamp=1500340472406, 
value=\x00\x00\x01]SBY\xC5
{code}

This was introduced by 
https://github.com/apache/hbase/blame/branch-1-HBASE-18147/hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java#L1464

It does not consider that case that regionInfo could come from a replica region.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18400) [C++] ConnectionId Equals/Hash should consider service_name

2017-07-17 Thread Xiaobing Zhou (JIRA)
Xiaobing Zhou created HBASE-18400:
-

 Summary: [C++] ConnectionId Equals/Hash should consider 
service_name
 Key: HBASE-18400
 URL: https://issues.apache.org/jira/browse/HBASE-18400
 Project: HBase
  Issue Type: Sub-task
Reporter: Xiaobing Zhou
Assignee: Xiaobing Zhou


Currently only security::User, host and port are taken into account in the 
implementation of ConnectionIdEquals and ConnectionIdHash. It makes sense to 
allocate dedicated RPC connection for a specific service, so service_name 
should be added to implementation;



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18399) Files in a snapshot can go missing even after the snapshot is taken successfully

2017-07-17 Thread Ashu Pachauri (JIRA)
Ashu Pachauri created HBASE-18399:
-

 Summary: Files in a snapshot can go missing even after the 
snapshot is taken successfully
 Key: HBASE-18399
 URL: https://issues.apache.org/jira/browse/HBASE-18399
 Project: HBase
  Issue Type: Sub-task
Reporter: Ashu Pachauri


Files missing after the snapshot is taken (only applicable when the TTL for the 
TimeToLiveHFileCleaner is small, like the default 5 mins)
* SnapshotManifest#addRegion visits store_file_A, but is yet to write it to 
the manifest.
* store_file_A is marked as compacted away and HFileArchiver moves the file 
to archive.
* HFileCleaner comes in and sees the store_file_A in archive. It adds the 
file to the list of files that might need to be cleaned up.
* HFileCleaner's SnapshotHFileCleaner plugin is kicked in.
* SnapshotFileCache#getUnreferencedFiles also says that store_file_A is 
unreferenced and should be cleaned up (It has not yet been written to the 
manifest).
* SnapshotHFileCleaner is still going through rest of the files in archive.
* store_file_A reference is created and written to snapshot manifest.
* Snapshot verification runs and sees the store_file_A is present in 
archive, and thus the verification passes.
* Now, the SnapshotHFileCleaner finishes and TimeToLiveHFileCleaner is 
triggered. If TTL has passed since the store_file_A was moved to archive 
(SnapshotHFileCleaner could take easily several minutes to go through rest of 
the files), the TimeToLiveHFileCleaner also marks the file as deletable.
* Since all cleaner plugins marked file as deletable, the store_file_A is 
deleted.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18398) Snapshot operation fails with FileNotFoundException

2017-07-17 Thread Ashu Pachauri (JIRA)
Ashu Pachauri created HBASE-18398:
-

 Summary: Snapshot operation fails with FileNotFoundException
 Key: HBASE-18398
 URL: https://issues.apache.org/jira/browse/HBASE-18398
 Project: HBase
  Issue Type: Sub-task
  Components: snapshots
Reporter: Ashu Pachauri


Failing to take snapshot due to FileNotFoundException
* FlushSnapshotSubprocedure.RegionSnapshotTask takes a region level read 
lock
* Call to HRegion#addRegionToSnapshot.
* Call to SnapshotManifest#addRegion. This gets the current list of store 
files.
* RACE → File is marked as compacted away and HFileArchiver moves the file 
to archive under store level lock.
* SnapshotManifest#addRegion visits the stale list of store files one by 
one. It does a file.getStatus() call to get length of each file. Since the file 
object still points to the original file, file.getStatus() fails with 
FileNotFoundException.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18397) StoreFile accounting issues on branch-1.3 and branch-1

2017-07-17 Thread Mikhail Antonov (JIRA)
Mikhail Antonov created HBASE-18397:
---

 Summary: StoreFile accounting issues on branch-1.3 and branch-1
 Key: HBASE-18397
 URL: https://issues.apache.org/jira/browse/HBASE-18397
 Project: HBase
  Issue Type: Umbrella
  Components: regionserver, Scanners
Affects Versions: 1.3.0
Reporter: Mikhail Antonov
Priority: Critical
 Fix For: 1.3.2


This jira is an umbrella for a set of issues around store file accounting on 
branch-1.3 and branch-1 (I believe).

At this point I do believe that many / most of those issues are related to 
backport of HBASE-13082 done  long time ago. A number of related issues were 
identified and fixed previously, but some still yet to be debugged and fixed. I 
think that this class of problems prevents us from releasing 1.3.2 and moving 
stable pointer to branch 1.3 at this point, so marking as critical.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18396) Encode ZNode names to reduce ZooKeeper jute buffer length requirements and thus reduce memory usage

2017-07-17 Thread Karan Mehta (JIRA)
Karan Mehta created HBASE-18396:
---

 Summary: Encode ZNode names to reduce ZooKeeper jute buffer length 
requirements and thus reduce memory usage
 Key: HBASE-18396
 URL: https://issues.apache.org/jira/browse/HBASE-18396
 Project: HBase
  Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Karan Mehta


In our production environment, we hit the error {{ZooKeeper connectionLoss due 
to jute.maxbuffer len of 1M getting exceeded}}. Usually 1 MB is a lot, but in 
case of multi requests, it can exceed the maximum buffer length that is 
allocated.

This JIRA is a discussion for encoding various znode names. IMO, this will 
reduce the path lengths, thus reducing the size of buffer required as well as 
network packet size and also pack more requests in a single multi. As with 
encoding, this will introduce overhead, but we need to determine how feasible 
this idea is.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (HBASE-18385) Enable HLC for just the meta table

2017-07-17 Thread Appy (JIRA)

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

Appy resolved HBASE-18385.
--
Resolution: Fixed

> Enable HLC for just the meta table
> --
>
> Key: HBASE-18385
> URL: https://issues.apache.org/jira/browse/HBASE-18385
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Amit Patel
>Assignee: Amit Patel
>Priority: Trivial
> Attachments: HBASE-18385.HBASE-14070.HLC.001.patch
>
>
> This task covers the patch for enabling HLC for the meta table while keeping 
> the remaining tables by default use the system clock. The patch for this task 
> will be going against the 
> [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC]
>  branch with the intent that it would be added as a commit.
> Credit for this work goes to our [~saitejar].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18395) Update clock on region open and close

2017-07-17 Thread Amit Patel (JIRA)
Amit Patel created HBASE-18395:
--

 Summary: Update clock on region open and close
 Key: HBASE-18395
 URL: https://issues.apache.org/jira/browse/HBASE-18395
 Project: HBase
  Issue Type: Sub-task
Reporter: Amit Patel
Assignee: Amit Patel
Priority: Minor


This task covers the patch for updating the clock on region opening and 
closing. 

The patch would include the following:
* Addition of a new protobuf message type that contains a field for a timestamp
* Setting of timestamp field in building region open/close request and response 
messages
* Updating the clock upon receiving message

The patch for this task will be going against the HBASE-14070.HLC branch with 
the intent that it would be added as a commit.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18394) Allowing user to define levels of prefix of Rowkey to be also put into BloomFilter

2017-07-17 Thread Ethan Wang (JIRA)
Ethan Wang created HBASE-18394:
--

 Summary: Allowing user to define levels of prefix of Rowkey to be 
also put into BloomFilter
 Key: HBASE-18394
 URL: https://issues.apache.org/jira/browse/HBASE-18394
 Project: HBase
  Issue Type: Improvement
Reporter: Ethan Wang


For Time Series data, one common use case is get/scan by prefix of a row key. 
Such as:

RowKey:Scope.Metric.TimeStamp
Search by:  Scope*

In these case bloom filter is not leveraged. However if we store every prefix 
of row key into bloomfilter that will be a big over head. Let user to store 
only the prefix of certain level will be a good thing to have
 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Resolved] (HBASE-14161) Add hbase-spark integration tests to IT jenkins job

2017-07-17 Thread Sean Busbey (JIRA)

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

Sean Busbey resolved HBASE-14161.
-
   Resolution: Fixed
Fix Version/s: (was: 2.0.0)
   3.0.0

We don't have a branch-2 specific IT matrix job yet, but the master/3.0.0-SNAP 
IT job is now running the new test from HBASE-18175

> Add hbase-spark integration tests to IT jenkins job
> ---
>
> Key: HBASE-14161
> URL: https://issues.apache.org/jira/browse/HBASE-14161
> Project: HBase
>  Issue Type: Task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 3.0.0
>
>
> expand the set of ITs we run to include the new hbase-spark tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Reopened] (HBASE-14161) Add hbase-spark integration tests to IT jenkins job

2017-07-17 Thread Sean Busbey (JIRA)

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

Sean Busbey reopened HBASE-14161:
-
  Assignee: Sean Busbey

> Add hbase-spark integration tests to IT jenkins job
> ---
>
> Key: HBASE-14161
> URL: https://issues.apache.org/jira/browse/HBASE-14161
> Project: HBase
>  Issue Type: Task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0
>
>
> expand the set of ITs we run to include the new hbase-spark tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


Re: One problem about document change

2017-07-17 Thread Sean Busbey
Contributors and committers usually only worry about making documentation
changes to the master branch.

When it comes time to spin up release candidates for a new version, the
release manager usually copies the then-current state of documentation in
the master branch to the branch they'll be working from (in this case
branch-2). Sometimes that documentation is also tailored further to the
release line (e.g. to remove irrelevant feature discussion).

On Sun, Jul 16, 2017 at 9:16 AM, Guanghao Zhang  wrote:

> Hi, folks
>
> Now I am working on the asynchronous admin which is part of asynchronous
> client. The asynchronous client feature were pushed to branch-2 and master
> branch. But one confuse thing is about the document change. The book site
> is generated by master branch's code. So the document change should only be
> pushed to master branch? Or it should be pushed to branch-2 and master
> both, because this feature was merged to branch-2, too? I am not sure about
> this, so look forward to you guys' idea. Thanks.
>
> Guanghao Zhang
>


[jira] [Created] (HBASE-18393) hbase shell non-interactive broken

2017-07-17 Thread Samir Ahmic (JIRA)
Samir Ahmic created HBASE-18393:
---

 Summary: hbase shell non-interactive broken  
 Key: HBASE-18393
 URL: https://issues.apache.org/jira/browse/HBASE-18393
 Project: HBase
  Issue Type: Bug
  Components: scripts, shell
Affects Versions: 3.0.0
Reporter: Samir Ahmic
Assignee: Samir Ahmic


Here is error for command line:
{code}
$ echo "list" | ./hbase shell -n
2017-07-17 08:01:09,442 WARN  [main] util.NativeCodeLoader: Unable to load 
native-hadoop library for your platform... using builtin-java classes where 
applicable
ERROR NoMethodError: undefined method `encoding' for #>
Did you mean?  set_encoding
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (HBASE-18392) Add default value of ----movetimeout to rolling-restart.sh

2017-07-17 Thread Samir Ahmic (JIRA)
Samir Ahmic created HBASE-18392:
---

 Summary: Add default value of movetimeout to rolling-restart.sh
 Key: HBASE-18392
 URL: https://issues.apache.org/jira/browse/HBASE-18392
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 3.0.0
Reporter: Samir Ahmic
Assignee: Samir Ahmic
 Fix For: 3.0.0


We are calling graceful_stop.sh in rolling-restart.sh with following line 
{code}
"$bin"/graceful_stop.sh --config ${HBASE_CONF_DIR} --restart --reload -nob 
--maxthreads  \
${RR_MAXTHREADS} ${RR_NOACK} --movetimeout ${RR_MOVE_TIMEOUT} 
$hostname
{code} 
and if we not specified --movetimeout option while calling rolling-restart.sh  
--graceful script will not work. My propose is to add default value for this 
parameter same way we are doing in graceful_stop.sh



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)