Details
-
Sub-task
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
1.8.6
-
None
-
None
-
1.8.6 the bug did not exist in 1.7.8
Description
quoting from mail
in a customer project that just upgraded to grails 2.1 we hit a
deadlock at EMC.performOperationOnMetaClass line 809.
It is most likely to have been introduced with commit
cdc39843d361a1d6c519432913c5d30f20782e68
by Lari Hotari, trying to fix 3557.
Looking at
protected synchronized void performOperationOnMetaClass(Callable c) {
try {
writeLock.lock();
...
synchronized plus a lock looks indeed strange... the GROOVY-3557 removed all synchronized in that class, except the one on this method... MetaClass#initialize is the only other place I see this synchronized still being available... to keep compatibility, this is sadly required. Now... the question is why it does deadlock, and if it can be prevented
makes me think that a mixture of locks and synchronized
is not a good thing to have.
in general more than one lock is dangerous.
I would suggest that when it comes to concurrency issues in the core,
we should include Vaclav in the design.
see also:
http://grails.1312388.n4.nabble.com/Thread-Blocking-at-Groovy-ExpandoMetaclass-method-in-a-Grails-App-td4572990.html
https://jira.codehaus.org/browse/GROOVY-5249
https://jira.codehaus.org/browse/GROOVY-3557
any opinions or should I file an issue right away?
We need an issue showing the traces of the deadlock... right now I have a hard imagining how that synchronized could cause the deadlock. So please fill one
bye blackdrag
Providing a trace is difficult since no Exception is thrown.
Also, the deadlock appearance is not deterministic.
But when it comes, it invariantly stops at this method.