[VOTE] First release candidate for HBase 1.3.2 (RC1) is available

[Francis Liu]

Hi,

The second release candidate for Apache HBase 1.3.2 is available to
download and testing.

Artifacts are available here:

*https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.2RC1/
*

Maven artifacts are available in the staging repository:

*https://repository.apache.org/content/repositories/orgapachehbase-1205
*

All artifacts are signed with my code signing key D646D9F3, which is also
in the project KEYS file at

http://www.apache.org/dist/hbase/KEYS

these artifacts correspond to commit hash

1bedb5bfbb5a99067e7bc54718c3124f632b6e17 tagged as 1.3.2RC1.

HBase 1.3.2 is the second maintenance release in the HBase 1.3.z release
line, continuing on the theme of bringing a stable, reliable database to the
Hadoop and NoSQL communities. This release includes 256 resolved issues
since 1.3.1 released 11 months ago.

The full list of issues addressed is available at

*https://s.apache.org/aMSp *

and also in the CHANGES.txt file in the root directory of the source
tarball.

Please take a few minutes to verify the release and vote on
releasing it:

[ ] +1 Release this package as Apache HBase 1.3.2
[ ] +0 no opinion
[ ] -1 Do not release this package because...

This Vote will run for one week and close Mon Mar 26, 2018 22:00 PST.

Thanks

Re: [VOTE] HBase Thirdparty 2.1.0 RC0

[Ted Yu]

+1

Ran the hbase test suite with patch from HBASE-20223.
Checked test output - nothing unusual.

On Mon, Mar 19, 2018 at 4:31 PM, Ted Yu  wrote:

> I got the following when building master branch with the patch from 
> HBASE-20223
> :
>
> [ERROR]   The project org.apache.hbase:hbase-spark-it:3.0.0-SNAPSHOT
> (/a/hbase/hbase-spark-it/pom.xml) has 1 error
> [ERROR] 'dependencies.dependency.version' for
> commons-cli:commons-cli:jar is missing. @ 
> org.apache.hbase:hbase-spark-it:[unknown-version],
> /mnt/disk2/a/hbase/hbase-spark-it/pom.xml, line 231, column 17
> [ERROR]
> [ERROR]   The project org.apache.hbase:hbase-backup:3.0.0-SNAPSHOT
> (/a/hbase/hbase-backup/pom.xml) has 1 error
> [ERROR] 'dependencies.dependency.version' for
> commons-cli:commons-cli:jar is missing. @ 
> org.apache.hbase:hbase-backup:[unknown-version],
> /mnt/disk2/a/hbase/hbase-backup/pom.xml, line 110, column 17
>
> Using the following I was able to proceed with running unit tests:
>
> https://pastebin.com/1nBxaySF
>
> Will report back test result.
>
> Thanks
>
> On Mon, Mar 19, 2018 at 4:15 PM, Josh Elser  wrote:
>
>> Hi,
>>
>> Please consider the following as the 2.1.0 release of Apache HBase
>> Thirdparty.
>>
>> Source artifact, signatures, and checksums are available at
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdpart
>> y/hbase-thirdparty-2.1.0RC0/
>>
>> Git commit for the release candidate available at
>> https://git-wip-us.apache.org/repos/asf?p=hbase-thirdparty.g
>> it;a=commit;h=de125620dece453f49a56de5b328427dc534133f
>>
>> Maven repository available at https://repository.apache.org/
>> content/repositories/orgapachehbase-1206
>>
>> This vote will remain open for at least 72 hours (~2018/03/22 2300 GMT).
>> HBASE-20223 has a patch for branch-2.0 which supports this thirdparty
>> update (obligatory: have not run a full test suite locally with this
>> change  yet).
>>
>> Here's my +1
>>
>> - Josh
>>
>
>

[jira] [Created] (HBASE-20226) Performance Improvement Taking Large Snapshots In Remote Filesystems

[Saad Mufti (JIRA)]

Saad Mufti created HBASE-20226:
--

 Summary: Performance Improvement Taking Large Snapshots In Remote 
Filesystems
 Key: HBASE-20226
 URL: https://issues.apache.org/jira/browse/HBASE-20226
 Project: HBase
  Issue Type: Improvement
  Components: snapshots
Affects Versions: 1.4.0
 Environment: HBase 1.4.0 running on an AWS EMR cluster with the 
hbase.rootdir set to point to a folder in S3 
Reporter: Saad Mufti


When taking a snapshot of any table, one of the last steps is to delete the 
region manifests, which have already been rolled up into a larger overall 
manifest and thus have redundant information.

This proposal is to do the deletion in a thread pool bounded by 
hbase.snapshot.thread.pool.max . For large tables with a lot of regions, the 
current single threaded deletion is taking longer than all the rest of the 
snapshot tasks when the Hbase data and the snapshot folder are both in a remote 
filesystem like S3.

I have a patch for this proposal almost ready and will submit it tomorrow for 
feedback, although I haven't had a chance to write any tests yet.



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

[jira] [Created] (HBASE-20225) [RPC] Server does not say what version it is

[stack (JIRA)]

stack created HBASE-20225:
-

 Summary: [RPC] Server does not say what version it is
 Key: HBASE-20225
 URL: https://issues.apache.org/jira/browse/HBASE-20225
 Project: HBase
  Issue Type: Bug
  Components: rpc
Affects Versions: 2.0.0
Reporter: stack


Strange. Server does not tell clients what version it is. It is explicitly this 
way. See [1] from refguide appendix on rpc protocol where client says what it 
wants and server is silent unless it is unable to satisfy the client request. I 
suppose it made sense at the time trying to squeeze in protobuf handling into a 
pre-existing RPC but in hindsight, it seems a little silly we don't answer the 
Connection setup with a Connection setup response that has stuff like server 
version and capabilities.

Its not so much a problem for our clients currently but I'm in here because 
asynchbase is broke against hbase2 [2]; hbase2 removes support for 
getClosestRowOrBefore doing meta lookups; clients are supposed to do a reverse 
scan instead.

[~manolamancha] has just made a fix but you have to specify you are connecting 
to hbase2 which is not how asynchbase does it; in the past, asynchbase would 
just figure out what to do going off hints and exceptions thrown by our server.

Not sure there is anything to do here. I tried reto-fitting a connection 
response but it will break hbase1 clients which we need to avoid.

Here is yet another reason for our throwing away this home-grown RPC. New 
Project: put up an alternate port on which we'd provide a modern RPC, one that 
does streaming, etc., and basics like return server version.

1. http://hbase.apache.org/book.html#_server
2. https://github.com/OpenTSDB/asynchbase/issues/150#issuecomment-373949082



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

[jira] [Reopened] (HBASE-20214) Review of RegionLocationFinder Class

[Ted Yu (JIRA)]

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

Ted Yu reopened HBASE-20214:


> Review of RegionLocationFinder Class
> 
>
> Key: HBASE-20214
> URL: https://issues.apache.org/jira/browse/HBASE-20214
> Project: HBase
>  Issue Type: Improvement
>  Components: Balancer, master
>Affects Versions: 2.0.0
>Reporter: BELUGA BEHR
>Assignee: BELUGA BEHR
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20214.1.patch
>
>
> # Use SLF4J parameter logging
>  # Remove superfluous code
>  # Replace code with re-usable libraries where possible
>  # Use different data structure
>  # Small perf improvements
>  # Fix some checkstyle



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

Re: [VOTE] HBase Thirdparty 2.1.0 RC0

[Ted Yu]

I got the following when building master branch with the patch from HBASE-20223
:

[ERROR]   The project org.apache.hbase:hbase-spark-it:3.0.0-SNAPSHOT
(/a/hbase/hbase-spark-it/pom.xml) has 1 error
[ERROR] 'dependencies.dependency.version' for
commons-cli:commons-cli:jar is missing. @
org.apache.hbase:hbase-spark-it:[unknown-version],
/mnt/disk2/a/hbase/hbase-spark-it/pom.xml, line 231, column 17
[ERROR]
[ERROR]   The project org.apache.hbase:hbase-backup:3.0.0-SNAPSHOT
(/a/hbase/hbase-backup/pom.xml) has 1 error
[ERROR] 'dependencies.dependency.version' for
commons-cli:commons-cli:jar is missing. @
org.apache.hbase:hbase-backup:[unknown-version],
/mnt/disk2/a/hbase/hbase-backup/pom.xml, line 110, column 17

Using the following I was able to proceed with running unit tests:

https://pastebin.com/1nBxaySF

Will report back test result.

Thanks

On Mon, Mar 19, 2018 at 4:15 PM, Josh Elser  wrote:

> Hi,
>
> Please consider the following as the 2.1.0 release of Apache HBase
> Thirdparty.
>
> Source artifact, signatures, and checksums are available at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdpart
> y/hbase-thirdparty-2.1.0RC0/
>
> Git commit for the release candidate available at
> https://git-wip-us.apache.org/repos/asf?p=hbase-thirdparty.g
> it;a=commit;h=de125620dece453f49a56de5b328427dc534133f
>
> Maven repository available at https://repository.apache.org/
> content/repositories/orgapachehbase-1206
>
> This vote will remain open for at least 72 hours (~2018/03/22 2300 GMT).
> HBASE-20223 has a patch for branch-2.0 which supports this thirdparty
> update (obligatory: have not run a full test suite locally with this
> change  yet).
>
> Here's my +1
>
> - Josh
>

[VOTE] HBase Thirdparty 2.1.0 RC0

[Josh Elser]

Hi,

Please consider the following as the 2.1.0 release of Apache HBase 
Thirdparty.


Source artifact, signatures, and checksums are available at
https://dist.apache.org/repos/dist/dev/hbase/hbase-thirdparty/hbase-thirdparty-2.1.0RC0/

Git commit for the release candidate available at 
https://git-wip-us.apache.org/repos/asf?p=hbase-thirdparty.git;a=commit;h=de125620dece453f49a56de5b328427dc534133f


Maven repository available at 
https://repository.apache.org/content/repositories/orgapachehbase-1206


This vote will remain open for at least 72 hours (~2018/03/22 2300 GMT). 
HBASE-20223 has a patch for branch-2.0 which supports this thirdparty 
update (obligatory: have not run a full test suite locally with this 
change  yet).


Here's my +1

- Josh

[jira] [Resolved] (HBASE-19584) hbase-thirdparty L refer to items not actually in the src release

[Josh Elser (JIRA)]

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

Josh Elser resolved HBASE-19584.

  Resolution: Fixed
Assignee: Josh Elser
Hadoop Flags: Reviewed

Thanks, Mike!

> hbase-thirdparty L refer to items not actually in the src release
> ---
>
> Key: HBASE-19584
> URL: https://issues.apache.org/jira/browse/HBASE-19584
> Project: HBase
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Josh Elser
>Priority: Major
> Fix For: thirdparty-2.1.0
>
> Attachments: HBASE-19584.001.patch
>
>
> From [~elserj]'s vote on 2.0-RC0:
> {quote}
> * L not entirely accurate, IMO. They state that things are included in the 
> src release which are not. I think it would be more appropriate to push the 
> relevant information down into src/main/apppended-resources for each module 
> (e.g. hbase-shaded-protobuf would have 
> src/main/appended-resources/\{LICENSE,NOTICE}) which have the relevant L 
> content for the products being bundled. Thus, we'd have nothing in the 
> 3rdparty L which reflects the src release.
> {quote}



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

[jira] [Resolved] (HBASE-19560) create make-rc.sh for hbase-thirdparty

[Josh Elser (JIRA)]

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

Josh Elser resolved HBASE-19560.

  Resolution: Fixed
Hadoop Flags: Reviewed

Pushed. Thanks for the review, Mike!

> create make-rc.sh for hbase-thirdparty
> --
>
> Key: HBASE-19560
> URL: https://issues.apache.org/jira/browse/HBASE-19560
> Project: HBase
>  Issue Type: Task
>  Components: hbase-thirdparty
>Reporter: Mike Drob
>Assignee: Josh Elser
>Priority: Major
> Fix For: thirdparty-2.1.0
>
> Attachments: HBASE-19560.001.patch, HBASE-19560.002.patch
>
>
> Make it easier to automate the process...
> Some notes, may not correspond to exact commands I ran...
> {noformat}
> mvn clean deploy -Papache-release
> git tag -s HEAD
> git archive HEAD -o release.tar.gz
> gpg --sign release.tar.gz
> gpg --print-mds
> gpg --print-md MD5
> gpg --print-md SHA512
> {noformat}



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

Re: About time for 1.4.3

[Andrew Purtell]

36 resolved, 0 in progress, after JIRA cleanup


On Mon, Mar 19, 2018 at 2:55 PM, Andrew Purtell  wrote:

> There are 35 issues committed for 1.4.3, with 2 remaining in progress. I
> plan to do the promised Q1 2018 release at the end of this month, with RC
> by the end of this week.
>
> Over the weekend the head of branch-1.4 passed all tests 10 out of 10
> iterations, so we are in good shape in that regard.
>
> --
> Best regards,
> Andrew
>
>

[jira] [Resolved] (HBASE-20063) Port HBASE-19799 (Add web UI to rsgroup) to branch-1

[Andrew Purtell (JIRA)]

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

Andrew Purtell resolved HBASE-20063.

   Resolution: Later
 Assignee: (was: Andrew Purtell)
Fix Version/s: (was: 1.4.3)
   (was: 1.5.0)

There are some java 8-isms and a difficult problem with how to handle jsp pages 
meant for hbase-server that must be separated out into hbase-rsgroup on 
branch-1 and dynamically loaded. Not worth it at this time I think, so 
resolving as Later (probably Never)

> Port HBASE-19799 (Add web UI to rsgroup) to branch-1
> 
>
> Key: HBASE-20063
> URL: https://issues.apache.org/jira/browse/HBASE-20063
> Project: HBase
>  Issue Type: Task
>  Components: rsgroup, UI
>Reporter: Andrew Purtell
>Priority: Major
>




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

About time for 1.4.3

[Andrew Purtell]

There are 35 issues committed for 1.4.3, with 2 remaining in progress. I
plan to do the promised Q1 2018 release at the end of this month, with RC
by the end of this week.

Over the weekend the head of branch-1.4 passed all tests 10 out of 10
iterations, so we are in good shape in that regard.

-- 
Best regards,
Andrew

[jira] [Created] (HBASE-20224) Web UI is broken in standalone mode

[Umesh Agashe (JIRA)]

Umesh Agashe created HBASE-20224:


 Summary: Web UI is broken in standalone mode
 Key: HBASE-20224
 URL: https://issues.apache.org/jira/browse/HBASE-20224
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 2.0.0-beta-2
Reporter: Umesh Agashe
Assignee: Umesh Agashe
 Fix For: 2.0.0


Web UI doesn't show up in standalone mode on default port. This can be seen on 
master and branch-2.



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

Re: Looking at an hbase-thirdparty release

[Josh Elser]

On 3/19/18 11:02 AM, Josh Elser wrote:



On 3/16/18 8:06 PM, Stack wrote:

On Fri, Mar 16, 2018 at 3:48 PM, Josh Elser  wrote:


No qualms from me. 3.5.1 the desired version?



Yeah. Hopefully just a pom version bump.




The reason that brought me here was nothing that we do in our build
(running MR jobs via `hadoop jar`), so I don't think we need to rush.


On the no rush, this release has to happen before I can put up an RC0. 
Was

hoping to do that in the next week or two. Just saying...



Understood. Am looking at this one today. Thanks for keeping me honest :)


All -- any spare review cycles for these would be appreciated. I think 
we're essentially in "patch available" state for a 2.1.0 rc0. They're 
all pretty straightforward.


https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%20thirdparty-2.1.0%20and%20resolution%20%3D%20unresolved

(Thanks Umesh for a review already :))

Re: Looking at an hbase-thirdparty release

[Andrew Purtell]

Let's test out an actual RC

On Mon, Mar 19, 2018 at 11:46 AM, Josh Elser  wrote:

> Ran a quick test locally after update and things appear to be in the same
> ballpark.
>
> If you want, I can give you branches to test now, Andrew, or would you
> prefer to just wait for thirdparty RC to use for testing?
>
> On 3/16/18 5:46 PM, Andrew Purtell wrote:
>
>> +1 on protobuf. Any chance we can get a vote period long enough to do a
>> comparison perf / GC test? I can help.
>>
>> On Fri, Mar 16, 2018 at 2:41 PM, Stack  wrote:
>>
>> Probably too risky to do at this stage in the game but protobuf? We're on
>>> 3.3.1. Latest is 3.5.1 [1]: "Various performance optimizations." And
>>> Guava
>>> is 24.1 now. We're on 22.
>>>
>>> St.Ack
>>> 1. https://github.com/google/protobuf/releases
>>>
>>>
>>> On Fri, Mar 16, 2018 at 1:47 PM, Josh Elser  wrote:
>>>
>>> Give a shout if there's anything that you all think would be good to
 include in a new hbase-thirdparty release for HBase 2.0.

 I'm pulling in commons-cli as per https://issues.apache.org/jira
 /browse/HBASE-20201.

 If there's more that should come in, please let me know!


>>>
>>
>>
>>


-- 
Best regards,
Andrew

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

[jira] [Resolved] (HBASE-20201) HBase must provide commons-cli-1.4 for mapreduce jobs with H3

[Josh Elser (JIRA)]

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

Josh Elser resolved HBASE-20201.

Resolution: Done

Marking as "Done" – the actual fix will come with the upgrade to 
hbase-thirdparty 2.1.0.

No specific code changes to be done to HBase as a part of this specific problem.

> HBase must provide commons-cli-1.4 for mapreduce jobs with H3
> -
>
> Key: HBASE-20201
> URL: https://issues.apache.org/jira/browse/HBASE-20201
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Reporter: Romil Choksi
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20201.001.patch
>
>
> Been trying to get some pre-existing mapreduce tests working against HBase2.
> There's an inherent problem right now that hadoop-common depends on 
> commons-cli-1.2 and HBase depends on commons-cli-1.4. This means that if you 
> use {{$(hbase mapredcp)}} to submit a mapreduce job via {{hadoop jar}}, 
> you'll get an error like:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/commons/cli/DefaultParser
>     at 
> org.apache.hadoop.hbase.util.AbstractHBaseTool.isHelpCommand(AbstractHBaseTool.java:165)
>     at 
> org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:133)
>     at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
>     at 
> org.apache.hadoop.hbase.util.AbstractHBaseTool.doStaticMain(AbstractHBaseTool.java:270)
>     at hbase_it.App.main(App.java:85)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at org.apache.hadoop.util.RunJar.run(RunJar.java:239)
>     at org.apache.hadoop.util.RunJar.main(RunJar.java:153)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.commons.cli.DefaultParser
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>     at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>     ... 11 more{noformat}
> My guess is that in previous versions, we didn't have this conflict with 
> Hadoop (we were on the same version). Now, we're not.
> I see two routes:
>  # We just alter the mapredcp to include our "correct" commons-cli-1.4 on the 
> classpath and remind users to make use of the {{HADOOP_USER_CLASSPATH_FIRST}} 
> environment variable
>  # We put commons-cli into our hbase-thirdparty and stop using it directly.
> The former is definitely quicker, but I'm guessing the latter would insulate 
> us more nicely.
> Thoughts, [~stack], [~busbey], [~mdrob] (and others who have done H3 work?)



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

[jira] [Created] (HBASE-20223) Use hbase-thirdparty 2.1.0

[Josh Elser (JIRA)]

Josh Elser created HBASE-20223:
--

 Summary: Use hbase-thirdparty 2.1.0
 Key: HBASE-20223
 URL: https://issues.apache.org/jira/browse/HBASE-20223
 Project: HBase
  Issue Type: Task
  Components: dependencies
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0


Update hbase to account for the changes to hbase-thirdparty:
 * new (internal) protobuf version
 * shaded commons-cli
 * shaded commons-collections4



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

Re: Looking at an hbase-thirdparty release

[Josh Elser]

Ran a quick test locally after update and things appear to be in the 
same ballpark.


If you want, I can give you branches to test now, Andrew, or would you 
prefer to just wait for thirdparty RC to use for testing?


On 3/16/18 5:46 PM, Andrew Purtell wrote:

+1 on protobuf. Any chance we can get a vote period long enough to do a
comparison perf / GC test? I can help.

On Fri, Mar 16, 2018 at 2:41 PM, Stack  wrote:


Probably too risky to do at this stage in the game but protobuf? We're on
3.3.1. Latest is 3.5.1 [1]: "Various performance optimizations." And Guava
is 24.1 now. We're on 22.

St.Ack
1. https://github.com/google/protobuf/releases


On Fri, Mar 16, 2018 at 1:47 PM, Josh Elser  wrote:


Give a shout if there's anything that you all think would be good to
include in a new hbase-thirdparty release for HBase 2.0.

I'm pulling in commons-cli as per https://issues.apache.org/jira
/browse/HBASE-20201.

If there's more that should come in, please let me know!

[jira] [Resolved] (HBASE-20216) [thirdparty] Bundle commons-cli

[Josh Elser (JIRA)]

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

Josh Elser resolved HBASE-20216.

  Resolution: Fixed
Hadoop Flags: Reviewed

> [thirdparty] Bundle commons-cli
> ---
>
> Key: HBASE-20216
> URL: https://issues.apache.org/jira/browse/HBASE-20216
> Project: HBase
>  Issue Type: Improvement
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: thirdparty-2.0.1
>
> Attachments: HBASE-20216.001.patch
>
>
> commons-cli 1.2 and >=1.3.1 are incompatible. Hadoop is still on 1.2, while 
> HBase 2.0 is beyond.
> Best to start bundling this internally.



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

[jira] [Created] (HBASE-20222) Bundle commons-collections

[Josh Elser (JIRA)]

Josh Elser created HBASE-20222:
--

 Summary: Bundle commons-collections
 Key: HBASE-20222
 URL: https://issues.apache.org/jira/browse/HBASE-20222
 Project: HBase
  Issue Type: Task
  Components: thirdparty
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: thirdparty-2.0.1


commons-collections recently had some incompatibilities in their packaging 
(between 3 and 4). Let's include it in our shaded-misc jar to avoid any 
potential problems in the future.



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

[jira] [Created] (HBASE-20221) Upgrade protobuf to 3.5.1

[Josh Elser (JIRA)]

Josh Elser created HBASE-20221:
--

 Summary: Upgrade protobuf to 3.5.1
 Key: HBASE-20221
 URL: https://issues.apache.org/jira/browse/HBASE-20221
 Project: HBase
  Issue Type: Task
  Components: thirdparty
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: thirdparty-2.0.1


Get hbase2 onto the latest protobuf because it's there.



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

Re: Looking at an hbase-thirdparty release

[Josh Elser]

I'll pull this in today as well. Like you say, this shouldn't have more 
issues -- we'll find out soon :)


On 3/17/18 4:20 PM, Mike Drob wrote:

Yea, I'm not concerned about commons-collections3 v commons-collections4 or
whatever the latest libs may be. I'm more concerned about collections4.1 v
4.2 or something like that, and I really hope that we don't have to redo
our import statements for each minor release.

On Fri, Mar 16, 2018 at 5:58 PM, Josh Elser  wrote:


Yeah, all of the commons-* projects worry me.

Recently, commons-math and commons-collections introduced different GAV
and java-package which give me some hope that they'll be OK going forward.

Not sure about IO, crypto, and lang..


On 3/16/18 6:19 PM, Mike Drob wrote:


commons-collections? I don't know what their minor version compatibility
story is, but that seems like a place that this could easily come up again
in the not so distant future.

On Fri, Mar 16, 2018 at 4:46 PM, Andrew Purtell 
wrote:

+1 on protobuf. Any chance we can get a vote period long enough to do a

comparison perf / GC test? I can help.

On Fri, Mar 16, 2018 at 2:41 PM, Stack  wrote:

Probably too risky to do at this stage in the game but protobuf? We're on

3.3.1. Latest is 3.5.1 [1]: "Various performance optimizations." And


Guava


is 24.1 now. We're on 22.

St.Ack
1. https://github.com/google/protobuf/releases


On Fri, Mar 16, 2018 at 1:47 PM, Josh Elser  wrote:

Give a shout if there's anything that you all think would be good to

include in a new hbase-thirdparty release for HBase 2.0.

I'm pulling in commons-cli as per https://issues.apache.org/jira
/browse/HBASE-20201.

If there's more that should come in, please let me know!







--
Best regards,
Andrew

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

Re: Looking at an hbase-thirdparty release

[Josh Elser]

On 3/16/18 8:06 PM, Stack wrote:

On Fri, Mar 16, 2018 at 3:48 PM, Josh Elser  wrote:


No qualms from me. 3.5.1 the desired version?



Yeah. Hopefully just a pom version bump.




The reason that brought me here was nothing that we do in our build
(running MR jobs via `hadoop jar`), so I don't think we need to rush.



On the no rush, this release has to happen before I can put up an RC0. Was
hoping to do that in the next week or two. Just saying...



Understood. Am looking at this one today. Thanks for keeping me honest :)

[jira] [Created] (HBASE-20220) [RSGroup] Check if table exists in the cluster before moving it to the specified regionserver group

[Guangxu Cheng (JIRA)]

Guangxu Cheng created HBASE-20220:
-

 Summary: [RSGroup] Check if table exists in the cluster before 
moving it to the specified regionserver group
 Key: HBASE-20220
 URL: https://issues.apache.org/jira/browse/HBASE-20220
 Project: HBase
  Issue Type: Improvement
  Components: rsgroup
Affects Versions: 3.0.0
Reporter: Guangxu Cheng
Assignee: Guangxu Cheng


move_tables_rsgroup/move_servers_tables_rsgroup can move non-existent tables in 
the cluster to the specified regionserver group successfully.It's not 
reasonable.We should check whether the table has already existed in the cluster 
before moving the table.



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