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 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.palache...@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 10 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.
>>
