[
https://issues.apache.org/jira/browse/HBASE-12431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14233524#comment-14233524
]
stack edited comment on HBASE-12431 at 12/3/14 9:17 PM:
--------------------------------------------------------
Changed my mind. Removing my +1.
Can the allocation of the thread local be lazily done?
Or, can this buffer not just be a local allocation? We are 'saving' on
allocating each time through a rarely used code path.
was (Author: stack):
+1
> Use of getColumnLatestCell(byte[], int, int, byte[], int, int) is Not Thread
> Safe
> ---------------------------------------------------------------------------------
>
> Key: HBASE-12431
> URL: https://issues.apache.org/jira/browse/HBASE-12431
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.98.1
> Reporter: Jonathan Jarvis
> Assignee: Jingcheng Du
> Fix For: 1.0.0, 2.0.0, 0.98.9
>
> Attachments: HBASE-12431-V2.diff, HBASE-12431-V3.diff,
> HBASE-12431.diff
>
>
> Result declares that it is NOT THREAD SAFE at the top of the source code, but
> one would assume that refers to many different threads accessing the same
> Result object. I've run into an issue when I have several different threads
> accessing their own Result object that runs into an issue because of use of
> common static member variable.
> I noticed the problem when I switched from:
> getColumnLatestCell(byte[], byte[]) to
> getColumnLatestCell(byte[], int, int, byte[], int, int)
> These methods call different binarySearch methods, the latter invoking:
> protected int binarySearch(final Cell [] kvs,
> 309 final byte [] family, final int foffset, final int flength,
> 310 final byte [] qualifier, final int qoffset, final int qlength) {
> This method utilizes a private static member variable called "buffer"
> If more than one thread is utilizing "buffer" you'll see unpredictable
> behavior unless you synchronize(Result.class) {}.
> If buffer is to remain a static variable, I would recommend changing it to a
> ThreadLocal<byte[]> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)