Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of todd@cloudera.com designates
 209.85.161.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <EA530668F4784C1987BF40FCB125E017@china.huawei.com>
References: 
 <CADcMMgG0owJjkLZsetWzq_2qdDZtzaqeVT4QEGAR2iuAkkx0EA@mail.gmail.com>
 <EA530668F4784C1987BF40FCB125E017@china.huawei.com>
From: Todd Lipcon <todd@cloudera.com>
Date: Wed, 2 Nov 2011 10:21:49 -0700
Message-ID: 
 <CADY20s4ucUJkw4Wi+mLtfL4ZBcdfEnMoJCQP0yi2Ktj6G8jqEA@mail.gmail.com>
Subject: Re: client thread waiting infinitely
To: dev@hbase.apache.org, ramakrishnas@huawei.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I've seen TreeMap infinite loop when it's concurrently modified
without locking. My bet is there's a threading bug.

-Todd

On Wed, Nov 2, 2011 at 7:12 AM, Ramkrishna S Vasudevan
<ramakrishnas@huawei.com> wrote:
> I said the Map could be corrupted because i dint view it as a JVM bug :).
>
> When i went through the code found like synchronization was taken care. =
=A0I
> will dig in more into this. Thanks Stack.
>
> Regards
> Ram
>
>
> -----Original Message-----
> From: saint.ack@gmail.com [mailto:saint.ack@gmail.com] On Behalf Of Stack
> Sent: Wednesday, November 02, 2011 7:30 PM
> To: dev@hbase.apache.org; ramakrishnas@huawei.com
> Subject: Re: client thread waiting infinitely
>
> On Tue, Nov 1, 2011 at 11:23 PM, Ramkrishna S Vasudevan
> <ramakrishnas@huawei.com> wrote:
>> JVM version is 1.6. =A0There was no profiling done.
>> In the TreeMap remove method we try to compare and then remove. =A0So ma=
y be
>> its not able to find the intended key as the map is corrupted and hence
> the
>> comparator is stuck and runs infinitely.
>>
>
> Is it a recent 1.6 JVM? =A0Perhaps a bug in JVM?
>
> Otherwise, can you reproduce?
>
> Why you think the Map 'corrupt'?
>
> St.Ack
>
>


--=20
Todd Lipcon
Software Engineer, Cloudera