Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

asynchbase does not work w/ hbase master branch (hbase-2.0.0); getClosestRowOrBefore was removed #150

Closed
saintstack opened this issue Nov 1, 2016 · 13 comments

Comments

@saintstack
Copy link
Contributor

In master branch which will become hbase-2.0.0, the deprecated getClosestRowOrBefore has been removed. This makes it so asynchbase fails out immediately unable to locate tables/regions in hbase:meta.

A few things:

  • getClosestRowOrBefore was deprecated and replace by a short Scan -- one that does open, scan, and close all in the one RPC -- running in reverse. I see that reverse has been added in the 'next' branch but no special short Scan so would have to do a Scan in reverse of one row only.
  • I wanted to do this change only if the server-version was 2.0.0. HBase now returns server-version in the connection header protobuf read on initial connection but asynchbase has always figured what approximate version hbase is at by probing and fallback.... so there is no means of reading the hbase server version currently. Would have to add it.
  • I wanted to do the reverse scan only if hbase server-version is >= 1.1.0 because this is when it started being used to do the hbase:meta lookups internally (reverse scanning was added for 1.0.0; getClosestRowOrBefore was deprecated before this).

I'm not too up on asynchbase. If anyone who knows it better is up for working on this, I'd be up for helping out. We'd need to add in some decent tests to ensure asynchbase always did the right thing. I could help here too.

@SahilAggarwal
Copy link

SahilAggarwal commented Mar 7, 2018

@saintstack Giving it a shot as beginner, pardon me if trivial questions asked :)

  • Clear on 1, tested it by doing reverse Scan of one row in getClosestRowBefore when version is > 1.1.0 with hbase-2.(hard coded server_version for now) and it was able to locate the region.
  • Not able to figure out how to read the server-version. We write header on channel after channelConnected but i don't see server sending anything back after getting this header. Am i missing anything?

@manolama
Copy link
Member

Ok, finally taking a look at this. It would be nice if HBase could throw an exception on calls to getClosestRowOrBefore but if we can parse out the server version that'll be fine. Thanks!

@manolama
Copy link
Member

@SahilAggarwal Got any code for the short-scan?

@manolama
Copy link
Member

@saintstack A simple reverse scanner like that in the MetaTableAccessor seems to work fine, easy tweak.

The only problem I see is that HBase 2.0.0-beta-2 doesn't seem to be responding to the ConnectionHeader RPC from the client, it just reads it and leaves the connection open if everything was good like previous versions of HBase. I couldn't find any server code that created a VersionInfo to send to the client. I only found the client instantiating a VersionInfo and sending it to the server.

Any other way we could probe the version? If not I can just add a config flag that folks would have to set marking it as 2.x

manolama added a commit to manolama/asynchbase that referenced this issue Mar 17, 2018
…t should

be set when HBase 2.x is used. This will turn on reverse scanning for meta
information as opposed to the old way of calling getClosestRowBefore().
As part of this, some callbacks in the Scanner class are now package private
so we can re-use them in HBaseClient.java.
Fixes OpenTSDB#150 Thanks @saintstack

TODO - need to see how this behaves with split meta.
TODO - I'd still like to auto-detect HBase 2.0 somehow.
manolama added a commit to manolama/asynchbase that referenced this issue Mar 17, 2018
…t should

be set when HBase 2.x is used. This will turn on reverse scanning for meta
information as opposed to the old way of calling getClosestRowBefore().
As part of this, some callbacks in the Scanner class are now package private
so we can re-use them in HBaseClient.java.
Fixes OpenTSDB#150 Thanks @saintstack

TODO - need to see how this behaves with split meta.
TODO - I'd still like to auto-detect HBase 2.0 somehow.
manolama added a commit to manolama/asynchbase that referenced this issue Mar 17, 2018
…t should

be set when HBase 2.x is used. This will turn on reverse scanning for meta
information as opposed to the old way of calling getClosestRowBefore().
As part of this, some callbacks in the Scanner class are now package private
so we can re-use them in HBaseClient.java.
Fixes OpenTSDB#150 Thanks @saintstack

TODO - need to see how this behaves with split meta.
TODO - I'd still like to auto-detect HBase 2.0 somehow.
manolama added a commit that referenced this issue Mar 17, 2018
…t should

be set when HBase 2.x is used. This will turn on reverse scanning for meta
information as opposed to the old way of calling getClosestRowBefore().
As part of this, some callbacks in the Scanner class are now package private
so we can re-use them in HBaseClient.java.
Fixes #150 Thanks @saintstack

TODO - need to see how this behaves with split meta.
TODO - I'd still like to auto-detect HBase 2.0 somehow.

Signed-off-by: Chris Larsen <clarsen@yahoo-inc.com>
@saintstack
Copy link
Contributor Author

Thanks @manolama Let me try it out. Thats great.

Yeah, I'd forgotten how our RPC works but yeah, Server sends nothing back post-Connection [1]. It should but it doesn't. It only complains if the Client asks for something it is unable to provide. I opened an issue on our side to address [2] but the best way would be to throw away our hand-done RPC (smile).

I poked around. There is nothing hbase2 specific around Connection setup that asynchbase could leverage unfortunately so could avoid this config which violates the asynchbase philosophy of just figuring it out by probing.

  1. http://hbase.apache.org/book.html#_server
  2. https://issues.apache.org/jira/browse/HBASE-20225

@manolama
Copy link
Member

Awesome, thanks for checking. One way I'm thinking of probing is to perform the getClosestRow call on meta for something like the 'hbase:namespace' that should always be present in 2.x. If it throws an exception or returns empty (as 2.0 currently does) then I could perform a reverse scan to confirm that it's picked up. Make sense @saintstack ?

@saintstack
Copy link
Contributor Author

@manolama Would it help if we put back getClosestRow... and threw an exception if it was called, UnsupportedOperationException? I'd have to check it didn't mess up old hbase-1.x clients but I don't think it will since they seem fine against hbase2. Could do this quick before we put up a hbase2 RC.

hbase:namespace should be there but it can take a while to show up.

@manolama
Copy link
Member

@saintstack Yeah if you return that exception it'd be perfect. Right now it just returns an empty response when I call getClosestRow. Thanks!

@saintstack
Copy link
Contributor Author

How is this @manolama ? Below is startup of a tsdb daemon against an hbase that has a patch that will throw UnknownProtocolException if client does a get with getClosestOrBefore set:


2018-03-20 22:40:09,231 INFO  [main] TSDB: Flushing compaction queue
2018-03-20 22:40:09,233 INFO  [main] HBaseClient: Channel [id: 0xd9575594, /127.0.0.1:56289 => /127.0.0.1:56264] is disconnecting: [id: 0xd9575594, /127.0.0.1:56289 => /127.0.0.1:56264] DISCONNECT
2018-03-20 22:40:09,233 INFO  [main] HBaseClient: Lost connection with the .META. region
2018-03-20 22:40:09,236 INFO  [main] TSDB: Completed shutting down the TSDB
Exception in thread "main" java.lang.RuntimeException: Initialization failed
	at net.opentsdb.tools.TSDMain.main(TSDMain.java:237)
Caused by: com.stumbleupon.async.DeferredGroupException: At least one of the Deferreds failed, first exception:
	at com.stumbleupon.async.DeferredGroup.done(DeferredGroup.java:169)
	at com.stumbleupon.async.DeferredGroup.recordCompletion(DeferredGroup.java:142)
	at com.stumbleupon.async.DeferredGroup.access$000(DeferredGroup.java:36)
	at com.stumbleupon.async.DeferredGroup$1Notify.call(DeferredGroup.java:82)
	at com.stumbleupon.async.Deferred.doCall(Deferred.java:1278)
	at com.stumbleupon.async.Deferred.runCallbacks(Deferred.java:1257)
	at com.stumbleupon.async.Deferred.access$300(Deferred.java:430)
	at com.stumbleupon.async.Deferred$Continue.call(Deferred.java:1366)
	at com.stumbleupon.async.Deferred.doCall(Deferred.java:1278)
	at com.stumbleupon.async.Deferred.runCallbacks(Deferred.java:1257)
	at com.stumbleupon.async.Deferred.handleContinuation(Deferred.java:1313)
	at com.stumbleupon.async.Deferred.doCall(Deferred.java:1284)
	at com.stumbleupon.async.Deferred.runCallbacks(Deferred.java:1257)
	at com.stumbleupon.async.Deferred.callback(Deferred.java:1005)
	at org.hbase.async.HBaseRpc.callback(HBaseRpc.java:712)
	at org.hbase.async.RegionClient.decode(RegionClient.java:1536)
	at org.hbase.async.RegionClient.decode(RegionClient.java:88)
	at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
	at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:485)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
	at org.hbase.async.RegionClient.handleUpstream(RegionClient.java:1226)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
	at org.jboss.netty.channel.SimpleChannelHandler.messageReceived(SimpleChannelHandler.java:142)
	at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88)
	at org.jboss.netty.handler.timeout.IdleStateAwareChannelHandler.handleUpstream(IdleStateAwareChannelHandler.java:36)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
	at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
	at org.jboss.netty.handler.timeout.IdleStateHandler.messageReceived(IdleStateHandler.java:294)
	at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
	at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
	at org.hbase.async.HBaseClient$RegionClientPipeline.sendUpstream(HBaseClient.java:3678)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
	at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
	at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108)
	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318)
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
	at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
	at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.hbase.async.RemoteException: org.apache.hadoop.hbase.exceptions.UnknownProtocolException: Support for getClosestRowBefore was removed in hbase-2.0.0
	at org.apache.hadoop.hbase.regionserver.RSRpcServices.get(RSRpcServices.java:2440)
	at org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:41791)
	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)

	at org.hbase.async.RegionClient.makeException(RegionClient.java:1758)
	at org.hbase.async.RegionClient.decodeException(RegionClient.java:1776)
	at org.hbase.async.RegionClient.decode(RegionClient.java:1488)
	at org.hbase.async.RegionClient.decode(RegionClient.java:88)
	at org.jboss.netty.handler.codec.replay.ReplayingDecoder.callDecode(ReplayingDecoder.java:500)
	at org.jboss.netty.handler.codec.replay.ReplayingDecoder.messageReceived(ReplayingDecoder.java:435)
	... 26 more

@manolama
Copy link
Member

Yeah that sounds good @saintstack, I can catch that and flip to scans easy.

@saintstack
Copy link
Contributor Author

@manolama Ok. Pushed HBASE-20237 You'll have to check out the tip of branch-2 to get it or play with the pending RC... Start of next week or so. Thanks.

@manolama
Copy link
Member

sweet, thanks!

@manolama
Copy link
Member

manolama commented Apr 3, 2018

@saintstack wanna peep #191 please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants