爲什麼HBase的節儉API總是返回一個節儉的客戶端連接

Question

對於每一個節儉API調用（二郎使用HBase的節儉），API返回舊貨連接：

二郎例如：

% creating the initial connection 

{ok, TFactory}   = thrift_socket_transport:new_transport_factory("localhost", 9090, []), 
{ok, PFactory}   = thrift_binary_protocol:new_protocol_factory(TFactory, []), 
{ok, Protocol}   = PFactory(), 
{ok, ThiftConnection1} = thrift_client:new(Protocol, hbase_thrift),  

%calling a row mutation 

{ThriftConnection2, Result} = thrift_client:call(ThriftConnection1, mutateRow, ["MYTABLE", Row1Id, MutationList1, dict:new()]), 
{ThriftConnection3, Result} = thrift_client:call(ThriftConnection2, mutateRow, ["MYTABLE", Row2Id, MutationList2, dict:new()]), 

這提出了以下相關的查詢：

1. 我應該總是使用返回的連接或只是第一個？
2. 這些連接是否相同？
3. 此傳遞連接方法會導致連接泄漏嗎？
4. 有沒有辦法關閉這些連接，或者他們有自己的 生命週期的每種類型的API調用使用它們？

Answer 1

我意識到這不是一個連接，而是一個節儉運輸的參考。我將它們相互比較，它們是相同的。在二郎，打印的內容（序列化）約每這些結果的事實表明它們是相同的

ThriftConnection2 : 
{tclient,hbase_thrift, 
{protocol,thrift_binary_protocol, 
    {binary_protocol, 
     {transport,thrift_buffered_transport, 
      {buffered_transport, 
       {transport,thrift_socket_transport, 
        {data,#Port<0.25469>,infinity}}, 
       []}}, 
     true,true}}, 
    0} 

ThriftConnection3 : 
{tclient,hbase_thrift, 
{protocol,thrift_binary_protocol, 
    {binary_protocol, 
     {transport,thrift_buffered_transport, 
      {buffered_transport, 
       {transport,thrift_socket_transport, 
        {data,#Port<0.25469>,infinity}}, 
       []}}, 
     true,true}}, 
    0}