Hello,
I have a query on OutOfOrderScannerNextException. I am using hbase 0.98.6 with
45 nodes.
I have a mapreduce job which scan 1 table for last 1 day worth data using
timerange. It has been running fine for months without any failure. But last
couple of days it has been failing with below
Sorry for misleading by specifying it as meta split. It was meta update
during a user region split. This had caused the stallation probably. We
have right now reverting client configs. Till now we didn't face the issue
again. Those changes causing some kindof exceptions or timeout was what we
Not very sure on what could be the problem when the meta update happened.
I would think that when the region split happened, there was some issue on
the meta update (as you said in the later mail). The splitted regions would
not have been updated properly in the META. So any client updates/reads
Thanks TED.
Regards,
Arun.
On Jun 6, 2015, at 2:34 PM, Ted Yu yuzhih...@gmail.com wrote:
HBASE-13090 'Progress heartbeats for long running scanners' solves the
problem you faced.
It is in the 1.1.0 release.
FYI
On Sat, Jun 6, 2015 at 12:54 PM, Arun Mishra arunmis...@me.com wrote:
Thanks Vladimir. I am using option 2 as a short term fix for now. I will
definitely look into key design.
Regards,
Arun.
On Jun 6, 2015, at 3:18 PM, Vladimir Rodionov vladrodio...@gmail.com wrote:
The scanner fails at the very beginning. The reason is because they need a
very few rows
HBASE-13090 'Progress heartbeats for long running scanners' solves the
problem you faced.
It is in the 1.1.0 release.
FYI
On Sat, Jun 6, 2015 at 12:54 PM, Arun Mishra arunmis...@me.com wrote:
Hello,
I have a query on OutOfOrderScannerNextException. I am using hbase 0.98.6
with 45 nodes.
The scanner fails at the very beginning. The reason is because they need a
very few rows from a large file and HBase needs
to fill RPC buffer (which is 100 rows, yes?) before it can return first
batch. This takes more than 60 sec and scanner fails (do not ask me why its
not the timeout exception)
We are also looking at increasing timestamp resolution in a backwards
compatible way (see https://issues.apache.org/jira/browse/HBASE-8927).
If we do introduce the concept of a timestamp multiplier per table, then
Bryan's suggestion could be an option without the regret. Clients could
learn the
HBase is a distributed, consistent, sorted key value store. The sorted bit
allows for range scans in addition to the point gets that all K/V stores
support. Nothing more, nothing less.
It happens to store its data in HDFS by default, and we provide convenient
input and output formats for map
