Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 4 Jan 2017 21:08:58 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13030177.1482424882000.642844.1483564138661@Atlassian.JIRA>
In-Reply-To: <JIRA.13030177.1482424882000@Atlassian.JIRA>
References: <JIRA.13030177.1482424882000@Atlassian.JIRA> <JIRA.13030177.1482424882427@arcas>
Subject: [jira] [Commented] (HBASE-17361) Make HTable thread safe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 04 Jan 2017 21:09:01 -0000


    [ https://issues.apache.org/jira/browse/HBASE-17361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15799345#comment-15799345 ] 

Enis Soztutar commented on HBASE-17361:
---------------------------------------

I like the idea of having the configuration parameters (timeout, etc) to be set-once at construction time. Then we don't have to deal with the user  changing configs on the fly. Our Connection / Table / BM already is a nice abstraction allowing that. If you want different timeout settings, you should instantiate a different Table object from Connection. 

The {{ConnectionConfiguration}} class used to be called {{TableConfiguration}}, but it was always {{InteraceAudience.Private}}. Maybe we can make a TableConfiguration, deprecate / remove all setXXX and have an API like this: 
{code}
TableConfiguration tableConf = connection.getTableConfigs();
tableConf.setRpcTimeout(42);
Table table = connection.getTable(tableName, tableConfigs);
{code}

HBASE-15645 introduced the setXXXTimeout() methods to Table it seems. 

> Make HTable thread safe
> -----------------------
>
>                 Key: HBASE-17361
>                 URL: https://issues.apache.org/jira/browse/HBASE-17361
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Yu Li
>            Assignee: Yu Li
>         Attachments: HBASE-17361.patch, HBASE-17361.patch
>
>
> Currently HTable is marked as NOT thread safe, and this JIRA target at improving this to take better usage of the thread-safe BufferedMutator.
> Some findings/work done:
> If we try to do put to the same HTable instance in parallel, there'll be problem, since now we have {{HTable#getBufferedMutator}} like
> {code}
>    BufferedMutator getBufferedMutator() throws IOException {
>      if (mutator == null) {
>       this.mutator = (BufferedMutatorImpl) connection.getBufferedMutator(
>           new BufferedMutatorParams(tableName)
>               .pool(pool)
>               .writeBufferSize(connConfiguration.getWriteBufferSize())
>               .maxKeyValueSize(connConfiguration.getMaxKeyValueSize())
>       );
>     }
>     mutator.setRpcTimeout(writeRpcTimeout);
>     mutator.setOperationTimeout(operationTimeout);
>     return mutator;
>   }
> {code}
> And {{HTable#flushCommits}}:
> {code}
>   void flushCommits() throws IOException {
>     if (mutator == null) {
>       // nothing to flush if there's no mutator; don't bother creating one.
>       return;
>     }
>     getBufferedMutator().flush();
>   }
> {code}
> For {{HTable#put}}
> {code}
>   public void put(final Put put) throws IOException {
>     getBufferedMutator().mutate(put);
>     flushCommits();
>   }
> {code}
> If we launch multiple threads to put in parallel, below sequence might happen because {{HTable#getBufferedMutator}} is not thread safe:
> {noformat}
> 1. ThreadA runs to getBufferedMutator and finds mutator==null
> 2. ThreadB runs to getBufferedMutator and finds mutator==null
> 3. ThreadA initialize mutator to instanceA, then calls mutator#mutate,
> adding one put (putA) into {{writeAsyncBuffer}}
> 4. ThreadB initialize mutator to instanceB
> 5. ThreadA runs to flushCommits, now mutator is instanceB, it calls
> instanceB's flush method, putA is lost
> {noformat}
> After fixing this, we will find quite some contention on {{BufferedMutatorImpl#flush}}, so more efforts required to make HTable thread safe but with good performance meanwhile.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)