ConcurrentModificationException won't release thread lock?!?!
Hi all,
My program is experiencing intermittent lock when it experienced ConcurrentModificationException and it won't release the thread lockl?!
This thread supposedly will only run for 1 min but its been 12 mins already and its not yet releasing the lock. It seems like because ConcurrentModificationException happened the lock was not release.
Im using java version "1.4.2_01"
1. Anybody knows what caused this?
2. Why is this happening intermittently? Some of my threads are not experiencing lock when they have ConcurrentModificationException.
3. How can i fix this? How can i avoid this?
Below is the dump of the thread that won't release the lock.
thanks in advance,
2224 root492M 324M sleep310 12:44.34 13% java/120
"net.Worker@176e552" prio=5 tid=0x008d1db8 nid=0x77 runnable [d7e01000..d7e019c0]
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.<init>(Throwable.java:180)
at java.lang.Exception.<init>(Exception.java:29)
at java.lang.RuntimeException.<init>(RuntimeException.java:32)
at java.util.ConcurrentModificationException.<init>(ConcurrentModificationException.java:57)
at java.util.Hashtable$Enumerator.next(Hashtable.java:980)
at net.Worker.decodeMessage(Worker.java:455)
- locked <0xe5a24ae0> (a net.Worker)
at net.Worker.onReceive(Worker.java:994)
at net.Worker.run(Worker.java:151)
[1516 byte] By [
leigh@@@a] at [2007-10-1 23:50:00]
I feel like you need to give more detail here, but it appears from what you have posted that the thread is stuck in the fillStackTrace native method. Since it's a native method, it's going to make a difference what OS you are running this on. Please provide that detail.
Hi,
Its running in Solaris 8, Sun OS 5.8.
thanks
> I feel like you need to give more detail here, but it
> appears from what you have posted that the thread is
> stuck in the fillStackTrace native method. Since
> it's a native method, it's going to make a difference
> what OS you are running this on. Please provide that
> detail.
> Hi,> > Its running in Solaris 8, Sun OS 5.8.> > thanksHave you searched the bug DB?
I've searched google and can't find anything related to my problem. But i havent checked the bug DB. Where can i find this?thanks,> Have you searched the bug DB?
> I've searched google and can't find anything related> to my problem. But i havent checked the bug DB. Where> can i find this? http://bugs.sun.com/bugdatabase/index.jsp
Is net.Worker your own code? If so, what is it doing on the lines mentioned in the stack trace?
MLRona at 2007-7-15 15:41:16 >
I've searched the bug database and its not there.Yes net.Worker is my code. The application encountered a ConcurrentModificationException. When this happened there are times the lock will be released there are times that it won't.
Does it always dump the same trace when it locks up?
It is iterating through a Hashtable using Iterator
Iterator myiter = mytable.keySet().iterator();
while(myiter .hasNext()){
String key = (String)myiter .next();
String value = (String)mytable.get(key);
}
> Does it always dump the same trace when it locks up?Yes almost the same trace, the only difference is this line"- locked <0xe5a24ae0> (a net.Worker)"
I know this isn't a very satisfying answer but you really need to eliminate the ConcurrentModificationExceptions from your code. You cannot depend on them to protect you from indeterminite behavior. From the ConcurentModificationException API:
Note that fail-fast behavior cannot be guaranteed as it is, generally
speaking, impossible to make any hard guarantees in the presence of
unsynchronized concurrent modification. Fail-fast operations throw
ConcurrentModificationException on a best-effort basis. Therefore, it
would be wrong to write a program that depended on this exception for
its correctness: ConcurrentModificationException should be used only
to detect bugs.
hi dubwai, yes i am aware of that but im just wondering why this behavior is intermittent. do you think its a bug in the jvm?
> hi dubwai, yes i am aware of that but im just
> wondering why this behavior is intermittent. do you
> think its a bug in the jvm?
Well, it's hard to say. Since the method it's hung up in is native, I can't see the code. It's anyone's quess as to why this is occuring. Does it happen with any other types of exceptions, that is, if you see any.
Oh, in case it's not understood, the lock is not released because this method is not returning. The lock is held father back in the stack.
> Does it happen with any other types of exceptions, that is, if you> see any.So far this is the only instance im experiencing this error. Do you think i should file this in the bug database? if yes, will it be under JVM or JDK category?
> > Does it happen with any other types of exceptions,
> that is, if you
> > see any.
>
> So far this is the only instance im experiencing this
> error. Do you think i should file this in the bug
> database? if yes, will it be under JVM or JDK
> category?
Yes, I would. From what you have here, it appears to be a bug.
> So far this is the only instance im experiencing this> error. Do you think i should file this in the bug> database? if yes, will it be under JVM or JDK> category?And JVM would be the category. The native methods are diffferent for different JVMs.
thanks dubwai for the help, i'll update this thread once i get a response from sun.
Hi!Did you have any newzs from Sun?Thanks.Go
I'd be surprised if this was accepted as a 'bug'. Perhaps an enhancment. Considering there are no guarantees when you perform a concurrent modification, you can not know what will happen. The javadoc seems to go to some lengths to express that there are no guarantees surrounding this behavior.
Nevertheless, Sun probably will desire to have a better way to deal with this than a thread lockup.
