I see this issue is closed but I experience the same problem with version 2.0.9 and under high load (10-15 requests/sec).
Here is part of thread dump log:
"TP-Processor3166" daemon prio=10 tid=0x00002aaabc693000 nid=0x39ef waiting for monitor entry [0x00000000677f7000] java.lang.Thread.State: BLOCKED (on object monitor) at org.directwebremoting.impl.DefaultScriptSessionManager.invalidate(DefaultScriptSessionManager.java:136) - waiting to lock <0x00000006b7a2add8> (a java.util.Collections$SynchronizedMap) at org.directwebremoting.impl.DefaultScriptSession.invalidate(DefaultScriptSession.java:109) at org.directwebremoting.impl.DefaultScriptSessionManager.checkTimeouts(DefaultScriptSessionManager.java:200)
DWR is used to call methods which execution lasts not more than 30sec.
Can somebody confirm that this problem is solved in version 2.0.9?
I believe any fix that removes the synchronization block around the loop in invalidate() will do the trick. It would be great if you could confirm this with realistic load in your environment.
After a two weeks on our live system we have no more blocked threads, It seems that ConcurrentHashMap solved this synchronization problem.
Thanks for checking back, Marjan.
We should get this fixed and release an updated 2.x version.
David, if you have something on the way here, go for it, otherwise feel free to assign to me.
I've updated the title to reflect reality better, shout if you don't agree.
I've now checked in an implementation that doesn't loop at all but instead saves the key where the cleanup is to be made upon invalidation. This should cause much less blocking behaviour.
Note: the discussion has mentioned ConcurrentHashMap which is not possible to use as DWR 2.x should compile on JDK 1.3 where this class is not available.