[jira] [Created] (HBASE-21011) Provide CLI option to run oldwals and hfiles cleaner separately

[Tak Lon (Stephen) Wu (JIRA)]

Tak Lon (Stephen) Wu created HBASE-21011:


 Summary: Provide CLI option to run oldwals and hfiles cleaner 
separately
 Key: HBASE-21011
 URL: https://issues.apache.org/jira/browse/HBASE-21011
 Project: HBase
  Issue Type: Improvement
  Components: Admin, Client
Affects Versions: 1.4.6, 3.0.0, 2.1.1
Reporter: Tak Lon (Stephen) Wu
Assignee: Tak Lon (Stephen) Wu


Existing logic of cleaner chore is first execute HFiles cleaner and then 
oldwals cleaner in a request, and only return succeed if both completes. 

There is a use case of running only oldwals cleaner because oldwals uses all 
the disk space, and running HFiles cleaner is too slow because either the 
amount of old HFiles or directories
 are too much. So, this change provide the flexibility for those disabled 
cleaner by default or would like to execute admin command to run oldwals and 
HFiles cleaning procedure individually.

NOTE that we keep the default as running both of them for backward 
compatibility, e.g. the proposed admin CLI options are 


{{ hbase> cleaner_chore_run}}
{{ hbase> cleaner_chore_run 'hfiles'}}
{{ hbase> cleaner_chore_run 'oldwals'}}



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

[jira] [Reopened] (HBASE-20829) Remove the addFront assertion in MasterProcedureScheduler.doAdd

[stack (JIRA)]

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

stack reopened HBASE-20829:
---

Reopen to backport to branch-2.0.2.

> Remove the addFront assertion in MasterProcedureScheduler.doAdd
> ---
>
> Key: HBASE-20829
> URL: https://issues.apache.org/jira/browse/HBASE-20829
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 2.0.2, 2.2.0
>
> Attachments: 
> 0001-HBASE-20829-Remove-the-addFront-assertion-in-MasterP.branch-2.0.patch, 
> HBASE-20829-debug.patch, HBASE-20829-v1.patch, HBASE-20829.patch, 
> org.apache.hadoop.hbase.replication.TestSyncReplicationStandbyKillRS-output.txt
>
>
> Timed out.
> {noformat}
> 2018-06-30 01:32:33,823 ERROR [Time-limited test] 
> replication.TestSyncReplicationStandbyKillRS(93): Failed to transit standby 
> cluster to DOWNGRADE_ACTIVE
> {noformat}
> We failed to transit the state to DA and then wait for it to become DA so 
> hang there.



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

[jira] [Created] (HBASE-21010) HBase Docker Development Environment

[Jack Bearden (JIRA)]

Jack Bearden created HBASE-21010:


 Summary: HBase Docker Development Environment 
 Key: HBASE-21010
 URL: https://issues.apache.org/jira/browse/HBASE-21010
 Project: HBase
  Issue Type: Improvement
Reporter: Jack Bearden
Assignee: Jack Bearden


Hi all,

I have been using the following environment (see patch) for conveniently 
building and testing my HBase patches before they hit precommit. This 
improvement is a port from Hadoop trunk that was modified to work in our 
codebase instead. This Linux environment should more closely resembles Jenkins.

Usage is simple, just run the script and it will build and run a docker 
container with your maven cache and hbase directory already set up. From there, 
you can execute your maven goals as usual.

As a kicker, this can also be used to run HBase in docker with low resources to 
perhaps sniff out and debug flakey tests. Again, not my work, but I was 
surprised it wasn't in master.



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

[jira] [Resolved] (HBASE-20969) Create an hbase-operator-tools repo to host hbck2 and later, other toolings

[stack (JIRA)]

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

stack resolved HBASE-20969.
---
  Resolution: Fixed
Assignee: stack
Release Note: Added new hbase-operator-tools.  See links below for 
repository location.

> Create an hbase-operator-tools repo to host hbck2 and later, other toolings
> ---
>
> Key: HBASE-20969
> URL: https://issues.apache.org/jira/browse/HBASE-20969
> Project: HBase
>  Issue Type: Sub-task
>  Components: hbase-operator-tools, hbck2
>Affects Versions: 2.0.1
>Reporter: stack
>Assignee: stack
>Priority: Major
>
> Let me make a new repo to host hbck2 and any other operator tools that make 
> sense to break off from core.
> See the discusion thread on dev [1] that blesses this project.
> 1. 
> http://apache-hbase.679495.n3.nabble.com/DISCUSS-Separate-Git-Repository-for-HBCK2-td4096319.html



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

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

[Jack Bearden]

Great work! I'm excited about this feature and want to help with
development. What do you guys suggest are the best topics to ramp up in
preparation for these upcoming sprints?

On Fri, Aug 3, 2018 at 10:18 AM, Josh Elser  wrote:

> Yup, we're on the same page :)
>
>
> On 7/26/18 1:28 PM, Zach York wrote:
>
>> I would REALLY hope that the WAL interface/API changes would go into
>> master
>> even if the feature work for Ratis is going in a feature branch. Not only
>> would this enable other backends to be developed in parallel with the
>> Ratis
>> solution if there are other good fits for a non-HDFS WAL, but also it
>> would
>> save the burden of having to rebase these core changes onto the latest
>> master to maintain compatibility. I'm assuming the Ratis portion of the
>> code would be mostly new files so these would be less of a concern.
>>
>> On Thu, Jul 26, 2018 at 9:24 AM, Josh Elser  wrote:
>>
>> On 7/26/18 1:00 AM, Stack wrote:
>>>
>>> All this said, I'd like to start moving toward the point where we start

> breaking out this work into a feature-branch off of master and start
> building code. My hope is that this is amenable to everyone, with the
> acknowledge that the Ratis work is considered "experimental" and not an
> attempt to make all of HBase use Ratis-backed WALs.
>
>
> Go for it.
>

 The branch would have WAL API changes only or would it include Ratis WAL
 dev? (If the latter, would that be better done over on Ratis project?).


>>> I think we would start with WAL API changes, get those "blessed", and
>>> then
>>> continue Ratis WAL dev after that.
>>>
>>>
>>

[jira] [Created] (HBASE-21009) Backport to branch-2.0 HBASE-20739 "Add priority for SCP"

[stack (JIRA)]

stack created HBASE-21009:
-

 Summary: Backport to branch-2.0 HBASE-20739 "Add priority for SCP"
 Key: HBASE-21009
 URL: https://issues.apache.org/jira/browse/HBASE-21009
 Project: HBase
  Issue Type: Sub-task
  Components: amv2
Reporter: stack
Assignee: stack
 Fix For: 2.0.2


Backport parent issue to branch-2.0.



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

[jira] [Created] (HBASE-21008) HBase 1.x can not read HBase2 hfiles due to TimeRangeTracker

[Jerry He (JIRA)]

Jerry He created HBASE-21008:


 Summary: HBase 1.x can not read HBase2 hfiles due to 
TimeRangeTracker
 Key: HBASE-21008
 URL: https://issues.apache.org/jira/browse/HBASE-21008
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.4.6, 2.1.0
Reporter: Jerry He


It looks like HBase 1.x can not open hfiiles written by HBase2 still.

I tested the latest HBase 1.4.6 and 2.1.0.  1.4.6 tried to read and open 
regions written by 2.1.0.

{code}
2018-07-30 16:01:31,274 ERROR [StoreFileOpenerThread-info-1] 
regionserver.StoreFile: Error reading timestamp range data from meta -- 
proceeding without
java.lang.IllegalArgumentException: Timestamp cannot be negative. 
minStamp:5783278630776778969, maxStamp:-4698050386518222402
at org.apache.hadoop.hbase.io.TimeRange.check(TimeRange.java:112)
at org.apache.hadoop.hbase.io.TimeRange.(TimeRange.java:100)
at 
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.toTimeRange(TimeRangeTracker.java:214)
at 
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.getTimeRange(TimeRangeTracker.java:198)
at 
org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:507)
at 
org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:531)
at 
org.apache.hadoop.hbase.regionserver.StoreFile.createReader(StoreFile.java:521)
at 
org.apache.hadoop.hbase.regionserver.HStore.createStoreFileAndReader(HStore.java:679)
at 
org.apache.hadoop.hbase.regionserver.HStore.access$000(HStore.java:122)
at org.apache.hadoop.hbase.regionserver.HStore$1.call(HStore.java:538)
at org.apache.hadoop.hbase.regionserver.HStore$1.call(HStore.java:535)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
{code}
Or:
{code}
2018-07-30 16:01:31,305 ERROR [RS_OPEN_REGION-throb1:34004-0] 
handler.OpenRegionHandler: Failed open of 
region=janusgraph,,1532630557542.b0fa15cb0bf1b0bf740997b7056c., starting to 
roll back the global memstore size.
java.io.IOException: java.io.IOException: java.io.EOFException
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1033)
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:908)
at 
org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:876)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6995)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6956)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6927)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6883)
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:6834)
at 
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.openRegion(OpenRegionHandler.java:364)
at 
org.apache.hadoop.hbase.regionserver.handler.OpenRegionHandler.process(OpenRegionHandler.java:131)
at 
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: java.io.EOFException
at 
org.apache.hadoop.hbase.regionserver.HStore.openStoreFiles(HStore.java:564)
at 
org.apache.hadoop.hbase.regionserver.HStore.loadStoreFiles(HStore.java:518)
at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:281)
at 
org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:5378)
at 
org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1007)
at 
org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1004)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
... 3 more
Caused by: java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java:197)
at java.io.DataInputStream.readLong(DataInputStream.java:416)
at 
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.readFields(TimeRangeTracker.java:170)
at 
org.apache.hadoop.hbase.util.Writables.copyWritable(Writables.java:161)
at 
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.getTimeRangeTracker(TimeRangeTracker.java:187)
at 
org.apache.hadoop.hbase.regionserver.TimeRangeTracker.getTimeRange(TimeRangeTracker.java:197)
at 
org.apache.hadoop.hbase.regionserver.StoreFile.open(StoreFile.java:507)
at 

[jira] [Created] (HBASE-21007) Memory leak in HBase rest server

[Bosko Devetak (JIRA)]

Bosko Devetak created HBASE-21007:
-

 Summary: Memory leak in HBase rest server
 Key: HBASE-21007
 URL: https://issues.apache.org/jira/browse/HBASE-21007
 Project: HBase
  Issue Type: Bug
  Components: REST
Affects Versions: 1.4.6, 1.4.0
Reporter: Bosko Devetak


When using the URIs like this:
 
          /sometable/*?limit=$limit=$startrow=$endrow
 
where *$limit* is smaller than the range between *$startrow* and *$endrow*, the 
rest server will start leaking memory.
 
 
The bug is in the *TableScanResource.java* class. Basically, the ResultScanner 
is not being closed in next() method when the limit has been reached.



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

Re: [DISCUSS] Expanded "work items" for HBase-in-the-Cloud doc

[Josh Elser]

Yup, we're on the same page :)

On 7/26/18 1:28 PM, Zach York wrote:

I would REALLY hope that the WAL interface/API changes would go into master
even if the feature work for Ratis is going in a feature branch. Not only
would this enable other backends to be developed in parallel with the Ratis
solution if there are other good fits for a non-HDFS WAL, but also it would
save the burden of having to rebase these core changes onto the latest
master to maintain compatibility. I'm assuming the Ratis portion of the
code would be mostly new files so these would be less of a concern.

On Thu, Jul 26, 2018 at 9:24 AM, Josh Elser  wrote:


On 7/26/18 1:00 AM, Stack wrote:


All this said, I'd like to start moving toward the point where we start

breaking out this work into a feature-branch off of master and start
building code. My hope is that this is amenable to everyone, with the
acknowledge that the Ratis work is considered "experimental" and not an
attempt to make all of HBase use Ratis-backed WALs.


Go for it.


The branch would have WAL API changes only or would it include Ratis WAL
dev? (If the latter, would that be better done over on Ratis project?).



I think we would start with WAL API changes, get those "blessed", and then
continue Ratis WAL dev after that.

[jira] [Created] (HBASE-21006) Balancer - data locality drops hugely after rolling restarts on cluster, not factoring in data locality enough?

[Hari Sekhon (JIRA)]

Hari Sekhon created HBASE-21006:
---

 Summary: Balancer - data locality drops hugely after rolling 
restarts on cluster, not factoring in data locality enough?
 Key: HBASE-21006
 URL: https://issues.apache.org/jira/browse/HBASE-21006
 Project: HBase
  Issue Type: Improvement
  Components: Balancer
Affects Versions: 1.1.2
 Environment: HDP 2.6
Reporter: Hari Sekhon


After doing rolling restarts of my HBase cluster the data locality drops by 
30-40% every time which implies the stochastic balancer is not optimizing for 
data locality enough, at least not under the circumstance of rolling restarts.

The stochastic balancer is supposed to take data locality in to account but if 
this is the case, surely it should move regions back to their original 
RegionServer and data locality should return back to around where it was, not 
drop by 30-40% percent every time I need to do some tuning and a rolling 
restarts.



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

[jira] [Created] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}

[Josh Elser (JIRA)]

Josh Elser created HBASE-21005:
--

 Summary: Maven site configuration causes downstream projects to 
get a directory named ${project.basedir}
 Key: HBASE-21005
 URL: https://issues.apache.org/jira/browse/HBASE-21005
 Project: HBase
  Issue Type: Bug
  Components: build
Affects Versions: 2.0.0
Reporter: Matt Burgess
Assignee: Josh Elser


Matt told me about this interesting issue they see down in Apache Nifi's build

NiFi depends on HBase for some code that they provide to their users. As a part 
of the build process of NiFi, they are seeing a directory named 
{{$\{project.basedir}}} get created the first time they build with an empty 
Maven repo. Matt reports that after a javax.el artifact is cached, Maven will 
stop creating the directory; however, if you wipe that artifact from the Maven 
repo, the next build will end up re-creating it.

I believe I've seen this with Phoenix, too, but never investigated why it was 
actually happening.

My hunch is that it's related to the local maven repo that we create to "patch" 
in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we can 
"work" around this by pushing the custom local repo into a profile and only 
activating that for the mvn-site. Another solution would be to publish the 
maven-fluido-jar to central with custom coordinates.



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

Re: access request to hbase slack channel

[Reid Chan]

Invitation sent

R.C



From: Bosko Devetak 
Sent: 03 August 2018 18:20:49
To: dev@hbase.apache.org
Subject: access request to hbase slack channel

Dear HBase community,

I have some questions regarding how to contribute bug fixes. Since it is
easier to communicate in realtime I would like to join the HBase Slack
channel, so I am writing to you to ask for an invite.

Best Regards,
Bosko.

--
Bosko Devetak
Senior Developer

Booking.com B.V.
Vijzelstraat 66-80 Amsterdam 1017HL Netherlands
Direct +31207158399
[image: Booking.com] 
The world's #1 accommodation site
43 languages, 198+ offices worldwide, 120,000+ global destinations,
1,550,000+ room nights booked every day
No booking fees, best price always guaranteed
Subsidiary of Booking Holdings Inc. (NASDAQ: BKNG)

Re: May I take this issue --hbase-spark

[nurseryboy]

hi Ted 
   You are right, one sample is from Hive,  our hive version is 2.3.3. 
  The hive sample is just to show the create table syntax, it will not
impact the hbase-spark part. 
   
   The demo I am preparing that, thank you. 
  
Regards
Bill 


Ted Yu-3 wrote
> bq. ROW FORMAT SERDE 'org.apache.hadoop.hive.hbase.HBaseSerDe'
> 
> The above implies dependency on some class from Hive.
> 
> Which Hive release would you use if you choose the above route ?
> 
> Looking forward to your demo.
> 
> On Tue, Jul 31, 2018 at 9:09 AM bill.yunfu 

> guangcheng.zgc@

> 
> wrote:
> 
>> hi Ted
>>Thank you for replying.
>> The sql support means user can directly use spark sql to create table and
>> query data from HBase. we found two sql support on HBase
>> SHC use following command to create table in spark sql:
>> CREATE TABLE spark_hbase USING
>> org.apache.spark.sql.execution.datasources.hbase
>>   OPTIONS ('catalog'=
>>   '{"table":{"namespace":"default", "name":"test",
>> "tableCoder":"PrimitiveType"},"rowkey":"key",
>>   "columns":{
>>   "col0":{"cf":"rowkey", "col":"key", "type":"string"},
>>   "col1":{"cf":"cf", "col":"a", "type":"string"}}}'
>>   )
>> (SHC is a project can get details from:
>> https://github.com/hortonworks-spark/shc)
>> In spark sql also can use hive command to create table:
>> create  table spark_hbase (col0 string, col1 string)
>> ROW FORMAT SERDE 'org.apache.hadoop.hive.hbase.HBaseSerDe' with
>> SERDEPROPERTIES ("hbase.columns.mapping" = ":key,cf:a")
>> STORED AS
>> INPUTFORMAT
>> 'org.apache.hadoop.hive.hbase.HiveHBaseTableInputFormat'
>> OUTPUTFORMAT
>> 'org.apache.hadoop.hive.hbase.HiveHBaseTableOutputFormat'
>> tblproperties ("hbase.table.name" = "test");
>>
>> So we want make a similar DDL to create the table for hbase-spark model
>> and
>> query with the spark sql.
>>
>> And for the Spark release, we suggestion first target at spark 2.y, for
>> example the spark 2.2.2 which is stability now.
>>
>> We will create a demo base on hbase-spark model with sql support in
>> local,
>> then share here to discuss.
>>
>> Regards
>> Bill
>>
>>
>> Ted Yu-3 wrote
>> > For SQL support, can you be more specific on how the SQL support would
>> be
>> > added ?
>> >
>> > Maybe you can illustrate some examples showing the enhanced SQL syntax.
>> >
>> > Also, which Spark release(s) would be targeted?
>> >
>> > Thanks
>> >
>> > On Mon, Jul 30, 2018 at 10:57 AM bill.yunfu 
>>
>> > guangcheng.zgc@
>>
>> > 
>> > wrote:
>>
>>
>>
>>
>>
>> --
>> Sent from:
>> http://apache-hbase.679495.n3.nabble.com/HBase-Developer-f679493.html
>>





--
Sent from: http://apache-hbase.679495.n3.nabble.com/HBase-Developer-f679493.html

[jira] [Created] (HBASE-21004) Backport to branch-2.0 HBASE-20708 "Remove the usage of RecoverMetaProcedure"

[stack (JIRA)]

stack created HBASE-21004:
-

 Summary: Backport to branch-2.0 HBASE-20708 "Remove the usage of 
RecoverMetaProcedure"
 Key: HBASE-21004
 URL: https://issues.apache.org/jira/browse/HBASE-21004
 Project: HBase
  Issue Type: Sub-task
  Components: amv2
Reporter: stack
Assignee: stack
 Fix For: 2.0.2


Backport parent issue to branch-2.0.



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

[jira] [Created] (HBASE-21003) Fix the flaky TestSplitOrMergeStatus

[Allan Yang (JIRA)]

Allan Yang created HBASE-21003:
--

 Summary: Fix the flaky TestSplitOrMergeStatus
 Key: HBASE-21003
 URL: https://issues.apache.org/jira/browse/HBASE-21003
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.0.1, 2.1.0
Reporter: Allan Yang
Assignee: Allan Yang


TestSplitOrMergeStatus.testSplitSwitch() is flaky because :
{code}
//Set the split switch to false
boolean[] results = admin.setSplitOrMergeEnabled(false, false, 
MasterSwitchType.SPLIT);
..
//Split the region
admin.split(t.getName());
int count = admin.getTableRegions(tableName).size();
assertTrue(originalCount == count);
//Set the split switch to true, actually, the last split procedure may not 
started yet on master
//So, after setting the switch to true, the last split operation may 
success, which is not 
//excepted   
results = admin.setSplitOrMergeEnabled(true, false, MasterSwitchType.SPLIT);
assertEquals(1, results.length);
assertFalse(results[0]);
//Since last split success, split the region again will end up with a 
//DoNotRetryRegionException here
admin.split(t.getName());
{code}

{code}
org.apache.hadoop.hbase.client.DoNotRetryRegionException: 
3f16a57c583e6ecf044c5b7de2e97121 is not OPEN; 
regionState={3f16a57c583e6ecf044c5b7de2e97121 state=SPLITTING, 
ts=1533239385789, server=asf911.gq1.ygridcore.net,60061,1533239369899}
 at 
org.apache.hadoop.hbase.master.procedure.AbstractStateMachineTableProcedure.checkOnline(AbstractStateMachineTableProcedure.java:191)
 at 
org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.(SplitTableRegionProcedure.java:112)
 at 
org.apache.hadoop.hbase.master.assignment.AssignmentManager.createSplitProcedure(AssignmentManager.java:756)
 at org.apache.hadoop.hbase.master.HMaster$2.run(HMaster.java:1722)
 at 
org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
 at org.apache.hadoop.hbase.master.HMaster.splitRegion(HMaster.java:1714)
 at 
org.apache.hadoop.hbase.master.MasterRpcServices.splitRegion(MasterRpcServices.java:797)
 at 
org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
 at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
 at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
 at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
 at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
{code}



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

access request to hbase slack channel

[Bosko Devetak]

Dear HBase community,

I have some questions regarding how to contribute bug fixes. Since it is
easier to communicate in realtime I would like to join the HBase Slack
channel, so I am writing to you to ask for an invite.

Best Regards,
Bosko.

-- 
Bosko Devetak
Senior Developer

Booking.com B.V.
Vijzelstraat 66-80 Amsterdam 1017HL Netherlands
Direct +31207158399
[image: Booking.com] 
The world's #1 accommodation site
43 languages, 198+ offices worldwide, 120,000+ global destinations,
1,550,000+ room nights booked every day
No booking fees, best price always guaranteed
Subsidiary of Booking Holdings Inc. (NASDAQ: BKNG)

Re: [DISCUSS] Kafka Connection, HBASE-15320

[Hbase Janitor]

I opened hbase-21002 to start the scripts and assembly.

Mike

On Thu, Aug 2, 2018, 19:29 Stack  wrote:

> Up in https://issues.apache.org/jira/browse/HBASE-20934 I created an
> hbase-connectors repo. I put some form on it using the v19 patch from
> HBASE-15320 "HBase connector for Kafka Connect". It builds and tests
> pass. Here are some remaining TODOs:
>
>  * Figure how to do start scripts: e.g. we need to start up the kafka
> proxy. It wants some hbase jars, conf dir, and others on the CLASSPATH
> (Depend on an HBASE_HOME and then source bin/hbase?)
>  * Can any of the connectors make-do with the shaded client?
>  * Make connectors standalone or have them share conf, bin, etc?
>  * Need to do an assembly. Not done.
>  * Move over REST and thrift next. Mapreduce after?
>
> The poms could do w/ a review. Hacked them over from hbase-thirdparty.
>
> File issues and apply patches up in JIRA if your up for any of the above.
>
> Thanks,
> S
>
> On Wed, Jul 25, 2018 at 10:46 PM Stack  wrote:
> >
> >
> > On Tue, Jul 24, 2018 at 10:01 PM Misty Linville 
> wrote:
> >>
> >> I like the idea of a separate connectors repo/release vehicle, but I'm a
> >> little concerned about the need to release all together to update just
> one
> >> of the connectors. How would that work? What kind of compatibility
> >> guarantees are we signing up for?
> >>
> >
> > I hate responses that begin "Good question" -- so fawning -- but, ahem,
> good question Misty (in the literal, not flattering, sense).
> >
> > I think hbase-connectors will be like hbase-thirdparty. The latter
> includes netty, pb, guava and a few other bits and pieces so yeah,
> sometimes a netty upgrade or an improvement on our patch to pb will require
> us releasing all though we are fixing one lib only. Usually, if bothering
> to make a release, we'll check for fixes or updates we can do in the other
> bundled components.
> >
> > On the rate of releases, I foresee a flurry of activity around launch as
> we fill missing bits and address critical bug fixes, but that then it will
> settle down to be boring, with just the occasional update. Thrift and REST
> have been stable for a good while now (not saying this is a good thing).
> Our Sean just suggested moving mapreduce to connectors too -- an
> interesting idea -- and this has also been stable too (at least until
> recently with the shading work). We should talk about the Spark connector
> when it comes time. It might not be as stable as the others.
> >
> > On the compatibility guarantees, we'll semver it so if an incompatible
> change in a connector or if the connectors have to change to match a new
> version of hbase, we'll make sure the hbase-connector version number is
> changed appropriately. On the backend, what Mike says; connectors use HBase
> Public APIs (else they can't be moved to the hbase-connector repo).
> >
> > S
> >
> >
> >
> >
> >
> >>
> >> On Tue, Jul 24, 2018, 9:41 PM Stack  wrote:
> >>
> >> > Grand. I filed https://issues.apache.org/jira/browse/HBASE-20934.
> Let me
> >> > have a go at making the easy one work first (the kafka proxy). Lets
> see how
> >> > it goes. I'll report back here.
> >> > S
> >> >
> >> > On Tue, Jul 24, 2018 at 2:43 PM Sean Busbey 
> wrote:
> >> >
> >> > > Key functionality for the project's adoption should be in the
> project.
> >> > > Please do not suggest we donate things to Bahir.
> >> > >
> >> > > I apologize if this is brisk. I have had previous negative
> experiences
> >> > > with folks that span our communities trying to move work I spent a
> lot
> >> > > of time contributing to within HBase over to Bahir in an attempt to
> >> > > bypass an agreed upon standard of quality.
> >> > >
> >> > > On Tue, Jul 24, 2018 at 3:38 PM, Artem Ervits <
> artemerv...@gmail.com>
> >> > > wrote:
> >> > > > Why not just donating the connector to http://bahir.apache.org/ ?
> >> > > >
> >> > > > On Tue, Jul 24, 2018, 12:51 PM Lars Francke <
> lars.fran...@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > >> I'd love to have the Kafka Connector included.
> >> > > >>
> >> > > >> @Mike thanks so much for the contribution (and your planned ones)
> >> > > >>
> >> > > >> I'm +1 on adding it to the core but I'm also +1 on having a
> separate
> >> > > >> repository under Apache governance
> >> > > >>
> >> > > >> On Tue, Jul 24, 2018 at 6:01 PM, Josh Elser 
> >> > wrote:
> >> > > >>
> >> > > >> > +1 to the great point by Duo about use of non-IA.Public classes
> >> > > >> >
> >> > > >> > +1 for Apache for the governance (although, I wouldn't care if
> we
> >> > use
> >> > > >> > Github PRs to try to encourage more folks to contribute), a
> repo
> >> > with
> >> > > the
> >> > > >> > theme of "connectors" (to include Thrift, REST, and the like).
> Spark
> >> > > too
> >> > > >> --
> >> > > >> > I think we had suggested that prior, but it could be a mental
> >> > > invention
> >> > > >> of
> >> > > >> > mine..
> >> > > >> >
> >> > > >> >
> >> > > >> > On 7/24/18 10:16 AM, Hbase Janitor wrote:
> >> > > 

[jira] [Created] (HBASE-21002) Create assembly and scripts to start Kafka Proxy

[Mike Wingert (JIRA)]

Mike Wingert created HBASE-21002:


 Summary: Create assembly and scripts to start Kafka Proxy
 Key: HBASE-21002
 URL: https://issues.apache.org/jira/browse/HBASE-21002
 Project: HBase
  Issue Type: Sub-task
  Components: hbase-connectors
Reporter: Mike Wingert
Assignee: Mike Wingert






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