Question about the HBase thrift server

[Varun Sharma <va...@pinterest.com>]

Hi everyone,

I have a question about the hbase thrift server and running scans in
particular. The thrift server maintains a map of <int> -> ResultScanner(s).
These integers are passed back to the client. Now in a typical setting
people run many thrift servers and round robin rpc(s) to them.

It seems that for scans, such a technique of just round robinning is simply
not going to work. If a scan integer ID has been retrieved from a certain
thrift server A, all the next() calls and close calls should fall on that
server.

I just wanted to make sure I got this thinking right and there isn't really
a way around this because scans, unlike gets have associated state.

Thanks !
Varun

Re: Question about the HBase thrift server

[Jean-Daniel Cryans <jd...@apache.org>]

That's right, round robin should only be applied when you start answering
some client request and stick to it until you're done.

J-D


On Fri, Dec 6, 2013 at 9:17 PM, Varun Sharma <va...@pinterest.com> wrote:

> Hi everyone,
>
> I have a question about the hbase thrift server and running scans in
> particular. The thrift server maintains a map of <int> -> ResultScanner(s).
> These integers are passed back to the client. Now in a typical setting
> people run many thrift servers and round robin rpc(s) to them.
>
> It seems that for scans, such a technique of just round robinning is simply
> not going to work. If a scan integer ID has been retrieved from a certain
> thrift server A, all the next() calls and close calls should fall on that
> server.
>
> I just wanted to make sure I got this thinking right and there isn't really
> a way around this because scans, unlike gets have associated state.
>
> Thanks !
> Varun
>