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 <[email protected] >> 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 < >>> [email protected]> 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. >>>> >> >>
