Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 11 Oct 2012 09:13:11 +0000 (UTC)
From: "Hiroshi Ikeda (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <595891548.25362.1349946791725.JavaMail.jiratomcat@arcas>
In-Reply-To: <1889014689.9155.1345778082653.JavaMail.jiratomcat@arcas>
Subject: [jira] [Updated] (HBASE-6651) Thread safety of HTablePool is
 doubtful
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/HBASE-6651?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hiroshi Ikeda updated HBASE-6651:
---------------------------------

    Attachment: HBASE-6651.patch

Added a patch.

Added a new interface SharedMap, and added its implementations and unit tes=
ts, and made HBaseClient and HTablePool use SharedMap instead of PoolMap. T=
he API of HTablePool is marked as =E2=80=9Cstable=E2=80=9D and some constru=
ctors of HTablePool uses a static nested class PoolMap.PoolType, and I=E2=
=80=99m not sure how to add Deprecated marker partially to PoolMap, so I di=
d nothing about it.

I don=E2=80=99t have environment to run the whole test of HBase, and except=
 tests added for SharedMap I only confirm that Eclipse can compile the patc=
hed code (where the projects are imported as =E2=80=9Cexisting maven projec=
ts=E2=80=9D from the trunk). I hope it will work well.

I purged ThreadLocal base logic from HBaseClient (that logic is terrible an=
d I never believe that works well). Instead, I complicate the Round-Robin b=
ased logic to prefer to give idle connections to requesters. I think, this =
is the same reason why the ThreadLocal based logic makes high performance. =
Moreover, in order to find idle objects in the pool, SharedMap has differen=
t methods from PoolMap, and I rewrote and fixed many parts of HBaseClient. =
On the other hand fixing HTablePool to SharedMap is straightforward and I t=
hink I have no additional explanations about it.


               =20
> Thread safety of HTablePool is doubtful
> ---------------------------------------
>
>                 Key: HBASE-6651
>                 URL: https://issues.apache.org/jira/browse/HBASE-6651
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.94.1
>            Reporter: Hiroshi Ikeda
>            Priority: Minor
>         Attachments: HBASE-6651.patch, sample.zip, sample.zip, sharedmap_=
for_hbaseclient.zip
>
>
> There are some operations in HTablePool to access to PoolMap in multiple =
times without any explict synchronization.=20
> For example HTablePool.closeTablePool() calles PoolMap.values(), and call=
es PoolMap.remove(). If other threads add new instances to the pool in the =
middle of the calls, the new added instances might be dropped. (HTablePool.=
closeTablePool() also has another problem that calling it by multple thread=
s causes accessing HTable by multiple threads.)
> Moreover, PoolMap is not thread safe for the same reason.
> For example PoolMap.put() calles ConcurrentMap.get() and calles Concurren=
tMap.put(). If other threads add a new instance to the concurent map in the=
 middle of the calls, the new instance might be dropped.
> And also implementations of Pool have the same problems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira