openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Palacherla <ravi.palache...@oracle.com>
Subject Re: Stuck threads at Schema.getTable.
Date Wed, 30 Mar 2011 02:07:05 GMT
Hi Mike,

As the java doc recommends that structural modification of HashMap/TreeMap should be done
only with proper synchronization.
The bug was not considered to be java bug but a solution to synchronize the HashMap is recommended.

Hence I think we should synchronize the TreeMap in Schema.java to avoid the infinite loop
in TreeMap.get.

Here is a blog that explains the cause of this issue:
http://lightbody.net/blog/2005/07/hashmapget_can_cause_an_infini.html

Regards,
Ravi.

On Mar 28, 2011, at 12:52 PM, Michael Dick wrote:

> Hi Ravi,
> 
> It'd be nice to know which levels of Java it affects (I'm assuming the bug
> is fixed in some level). If it's not planned for Java 6 then we probably
> need to get the fix in.
> 
> -mike
> 
> On Mon, Mar 28, 2011 at 1:34 PM, Ravi Palacherla <ravi.palacherla@oracle.com
>> wrote:
> 
>> Hi Mike,
>> 
>> The link used to work till yesterday. I will see if I can find another link
>> that shows the issue.
>> 
>> It is not a sun bug but using an un-synchronized hashMap is resulting in
>> the hashmap to get corrupted and it is spinning for ever at hashmap.get
>> code.
>> 6423457 (coll) High cpu usage in HashMap.get()
>> 
>> This has been tracked as sun bug# 6423457 and the solution provided is to
>> synchronize the hashMap.
>> Even though the issue might have been triggered because of structural
>> modification of HashMap outside a synchronized block the thread dump shows
>> that the thread is stuck at HashMap.get.
>> 
>> The same customer had a similar issue previously with  TableJDBCSeq.java:
>> 
>> java.lang.Thread.State: RUNNABLE
>> @  at java.util.HashMap.__tc_get(Unknown Source)
>> @  at java.util.HashMap.get(Unknown Source)
>> @  at
>> @
>> org.apache.openjpa.jdbc.kernel.TableJDBCSeq.getStatus(TableJDBCSeq.java:308)
>> @  at
>> @
>> org.apache.openjpa.jdbc.kernel.TableJDBCSeq.nextInternal(TableJDBCSeq.java:25
>> @ 3)
>> 
>> This has been fixed by using concurrentHashMap as part of OPENJPA-1765.
>> 
>> 
>> I think the issue is similar but with TreeMap in openJPA's schema.java
>> code.
>> 
>> Here is a test code that I used to replicate the issue, but unsuccessful so
>> far:
>> 
>> public void testSchemaTable() throws InterruptedException {
>>     final Schema _schema = new SchemaGroup().addSchema("schema");
>> 
>>     for (int i=0;i<LOOPCOUNT;i++) {
>>                        _schema.addTable("Table:"+i);
>>                        count++;
>>         }
>> 
>>     Thread[] threads = new Thread[THREADS];
>> 
>>    for(int numThread=0; numThread< THREADS; numThread++) {
>>        if( numThread % (THREADS-10) == 0) {
>>                threads[numThread] = new Thread(new Runnable() {
>>                  public void run() {
>>                        int lc = LOOPCOUNT+count;
>>                    for (int i=count;i<lc;i++,count++) {
>>                      _schema.addTable("Table:"+i);
>>                    }
>>                  }
>>               });
>>        } else {
>>                threads[numThread] = new Thread(new Runnable() {
>>                  public void run() {
>>                        int lc = LOOPCOUNT+count;
>>                    for (int i=0;i<LOOPCOUNT;i++) {
>>                      _schema.getTable("Table:"+i);
>>                    }
>>                  }
>>               });
>>        }
>> 
>>    }
>> 
>>     for (int threadCount=0; threadCount<THREADS;threadCount++) {
>>       threads[threadCount].start();
>>     }
>> 
>>     for (int threadCount=0; threadCount<THREADS;threadCount++) {
>>       threads[threadCount].join();
>>     }
>>   }
>> 
>> 
>> Regards,
>> Ravi.
>> 
>> On Mar 28, 2011, at 11:00 AM, Michael Dick wrote:
>> 
>>> Hi Ravi,
>>> 
>>> The link didn't work for me, is this a bug in the TreeMap implementation?
>>> 
>>> Multithreaded reads of a TreeMap should be fine. If a thread is adding or
>>> deleting a node then we'll need to synchronize - is that what's happening
>> in
>>> your case?
>>> 
>>> I've cross posted to dev - might get a better audience there.
>>> 
>>> -mike
>>> 
>>> On Sun, Mar 27, 2011 at 10:06 PM, Ravi P Palacherla <
>>> ravi.palacherla@oracle.com> wrote:
>>> 
>>>> Hi ,
>>>> 
>>>> I see following stuck threads in openJPA code :
>>>> 
>>>> java.lang.Thread.State: RUNNABLE
>>>> at java.util.TreeMap.getEntry(TreeMap.java:328)
>>>> at java.util.TreeMap.get(TreeMap.java:255)
>>>> at org.apache.openjpa.jdbc.schema.Schema.getTable(Schema.java:115)
>>>> 
>>>> I think the root cause of the issue is because of unsynchronized
>> TreeMap.
>>>> 
>>>> There is a sun issue that explains the same about a hashMap and I think
>>>> this
>>>> is also because of the same issue explained in:
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457
>>>> 
>>>> So, the fix is to synchronize the TreeMap but I do not have a replicable
>>>> test case.
>>>> 
>>>> I created a simple testcase that will create around 100000 treeMap
>> entries
>>>> and then around 50 threads trying to access this treeMap but unable to
>>>> replicate the issue.
>>>> 
>>>> Please suggest what you think should be done.
>>>> Can I just submit the code fix ( synchronizing the treemap) and the test
>>>> case ( even though unable to replicate ) ?
>>>> 
>>>> Regards,
>>>> Ravi.
>>>> 
>>>> --
>>>> View this message in context:
>>>> 
>> http://openjpa.208410.n2.nabble.com/Stuck-threads-at-Schema-getTable-tp6213602p6213602.html
>>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>> 
>> 
>> 


Mime
View raw message