python快速写入hbase_Python 读写 hbase 数据的正确姿势（四）

title: Python 读写 hbase 数据的正确姿势（四）

tags:

hbase

happybase

python

categories:

�Hbase

comments: true

date: 2017-10-08 16:00:00

问题4: 查询异常 TApplicationException: Missing result

在上一篇文章中讨论了线上测试时出现 [Errno 32] Broken pipe 错误，这里继续分析另一个错误 TApplicationException: Missing result。

问题描述

在解决了问题 3 后，又遇到了古怪的错误：在查询的过程中，出现了大量的 TApplicationException: Missing result 错误：

File "/usr/local/lib/python2.7/site-packages/happybase/table.py", line 402, in scan

self.name, scan, {})

File "/usr/local/lib/python2.7/site-packages/thriftpy/thrift.py", line 198, in _req

return self._recv(_api)

File "/usr/local/lib/python2.7/site-packages/thriftpy/thrift.py", line 234, in _recv

raise TApplicationException(TApplicationException.MISSING_RESULT)

thriftpy.thrift.TApplicationException: Missing result

而且，在大量出现此类错误之前伴有 timeout: timed out 超时：

File "/usr/local/lib/python2.7/site-packages/happybase/table.py", line 415, in scan

scan_id, how_many)

File "/usr/local/lib/python2.7/site-packages/thriftpy/thrift.py", line 198, in _req

return self._recv(_api)

File "/usr/local/lib/python2.7/site-packages/thriftpy/thrift.py", line 210, in _recv

fname, mtype, rseqid = self._iprot.read_message_begin()

File "thriftpy/protocol/cybin/cybin.pyx", line 429, in cybin.TCyBinaryProtocol.read_message_begin (thriftpy/protocol/cybin/cybin.c:6325)

File "thriftpy/protocol/cybin/cybin.pyx", line 60, in cybin.read_i32 (thriftpy/protocol/cybin/cybin.c:1546)

File "thriftpy/transport/buffered/cybuffered.pyx", line 65, in thriftpy.transport.buffered.cybuffered.TCyBufferedTransport.c_read (thriftpy/transport/buffered/cybuffered.c:1881)

File "thriftpy/transport/buffered/cybuffered.pyx", line 69, in thriftpy.transport.buffered.cybuffered.TCyBufferedTransport.read_trans (thriftpy/transport/buffered/cybuffered.c:1948)

File "thriftpy/transport/cybase.pyx", line 61, in thriftpy.transport.cybase.TCyBuffer.read_trans (thriftpy/transport/cybase.c:1472)

File "/usr/local/lib/python2.7/site-packages/thriftpy/transport/socket.py", line 108, in read

buff = self.sock.recv(sz)

timeout: timed out

服务端没有任何异常。

问题分析

看起来这种情况和上文问题 3 中Broken pipe + TTransportException 的错误组合模式比较类似，所以猜测timeout 是导致这种现象的导火索，为了验证猜想，尝试在测试环境手动复现错误场景：

conn_pool = None

TABLE = 'article'

# 本地环境 timeout 设置为1 时 超时较多

# 生产环境为 10

def get_connetion_pool(timeout=1):

global conn_pool

if conn_pool is None:

conn_pool = happybase.ConnectionPool(1, timeout=timeout)

return conn_pool

def recent_events_v3(start, end, table=None, filter_str=None, limit=2000):

with get_connetion_pool().connection() as conn:

if table is not None:

t = conn.table(table)

else:

t = conn.table(TABLE)

start_row = 'ARTICLE' + str(start * 1000000)

end_row = 'ARTICLE' + str(end * 1000000)

return t.scan(row_start=start_row, row_stop=end_row, filter=filter_str, limit=limit)

def main():

# 问题4复现

for i in range(100):

# 有timeout，有 Missing result，有正常查询

try:

results = recent_events_v3(start=0, end=1505646570, table="test_article_java_2")

print len([i for i in results])

except Exception as e:

print e

print '#########################################'

运行结果如下：

image.png

而当把 timeout 增加到一个较大值时则不会出现这种情况。印证了猜想 TApplicationException: Missing result 异常前一定出现过 timeout。

解决问题

增大 timeout 后，可以很大程度上减少这样的情况发生，但是 timeout 不同于问题 3 的 IllegalArgumentException 错误，可以主动控制，使用 scan 的查询场景以及网络环境本身(在稳定的场景，仍有可能出现抖动导致超时) 难以避免的会出现 timeout，所以仅仅增加 timeout 值，仍然后可能会出现这种情况。

问题 3 会出现 Broken Pipe 错误是因为之前发生错误导致连接失效，后续再使用异常连接时则会报错。问题 4 是否也是因为 timeout 后导致连接出问题，然后出现这种情况呢？

尝试验证这种猜想：在发生 timeout 时，catch 住并重新初始化连接池然后重试：

def main():

# 问题4修复

for i in range(30):

# 没有 Missing result，只有 timeout 和 有正常查询

try:

results = recent_events_v3(start=0, end=1505646570, table="test_article_java_2")

print len([i for i in results]) # 期望值为2, 实际报错

except socket.timeout:

conn_pool = None # catch timeout 后, 清空连接池，下次使用时重新初始化, 仅限单线程模型 !

print 'time out: reinit conn pool!'

# print traceback.format_exc()

# 不会在出现 `TApplicationException: Missing result` 错误

print '#########################################'

修改后运行测试代码只会出现 timeout，不会出现其他错误:

timeout re init

因为生产环境是多容器，每个容器单进程，在这种场景下连接池和一个全局变量连接的意义相差不大，整个连接池同一时刻只会被一个进程使用(所以连接池只初始化了 1 条连接)，所以直接重置连接池是可以的，此时可以彻底避免 Missing results ~

继续思考

上文文末提到一个疑惑 ：为什么一条异常的连接会出现在 connect pool 中，而且总会拿到这条连接 ? 。

这次同样还有另一个问题值得思考：timeout 后为什么会出现大量的 Missing results 错误？是否如同猜测的那样 timeout 后连接池中的连接失效了？

下篇文章见~