批量get hbase频繁出现 waiting for 174 actions to finish on table类似的日志,看了下代码,客户端批量请求的时候维护一个共享变量
public void batch(final List<? extends Row> actions, final Object results) throws InterruptedException, IOException { AsyncRequestFuture ars = multiAp.submitAll(pool, tableName, actions, null, results);
ars.waitUntilDone();
if (ars.hasError()) { throw ars.getErrors(); }
}
在发送请求时会初始化这个变量为批次的大小,即这一批的数据行数。服务端返回数据后请求服务端的线程会根据返回的数据量对这个变量递减。如果返回的数据行数和请求的行数相等递减为0. batch操作结束本次请求数据结束。但是现在我遇到的情况时返回的数据数和请求的数据数不相等,args.waitUntilDone()这里面的代码就会无限循环输出下面的这种日志。
2018-10-11 16:58:13 [INFO] [org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl:1698] - #1, waiting for 85 actions to finish on table:
2018-10-11 16:58:24 [INFO] [org.apache.hadoop.hbase.client.AsyncProcess$AsyncRequestFutureImpl:1698] - #1, waiting for 85 actions to finish on table:
疑问点:
1.什么情况下会导致请求的数据行数和返回的数据行数不一致?
我这里看到一共还有85个actions在等待,一直刷了一天多的日志,只能重启程序。同时我看服务端的请求并发并不高,个人认为不是服务端处理不过来的原因。
2,当维护的共享变量(每次批请求的数据量会初始化这个共享变量,请求返回后会递减这个变量)不能递减到0时为什么会是无限循环输出日志的这种逻辑。(而且是info级别的日志)。?
出现这种请求一直积压的问题,对于客户端而言:个人认为,如果客户端没有出现异常,日志一直在刷,一般的问题就有可能是服务端没有处理掉action ,或者有region在split超时等。另外GC也会导致这样的问题;还有就是批次查询的量也应该设置一下,检查一下这方面的参数是否设置合理。以上只是个人意见,以实际情况为主,另外还是主要从日志方面着手查询原因
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。