[
https://issues.apache.org/jira/browse/LOGGING-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417062#comment-13417062
]
Sebb commented on LOGGING-119:
------------------------------
An alternative fix would be to drop the direct synch on queue, and synchronise
the methods that call it.
Eclipse complains about many of the methods, for example:
The method WeakHashtable.get(Object) is overriding a synchronized method
without being synchronized
I don't think there are any issues here, but most of the methods don't do much
except delegate to the super method, at which point the synch. lock will be
acquired anyway. So the additional synch. code would be minimal.
Fixing the Eclipse warnings leaves the following methods that call purge
without being synchronized:
entrySet()
keySet()
values()
rehash()
Synchronising these methods seems unlikely to adversely affect performance
compared with synchronising just the queue.
There is not much additional code included in the synch. block.
In the case of rehash(), it is only called by Hashtable#put() which is synch.
anyway.
==
It's not clear to me that the existing patch is 100% thread-safe.
There is a window between removing the item from the reference queue (poll) and
removing the referenced item from the hash table.
If another thread modifies the hashtable between the poll and the remove, can
that cause any problems?
Also, not all references to the queue field are protected by the same lock; the
put() method references the queue without first aquiring the queue lock.
Potentially this can cause a data publication issue due to the Java Memory
Model.
> deadlock on re-registration of logger
> -------------------------------------
>
> Key: LOGGING-119
> URL: https://issues.apache.org/jira/browse/LOGGING-119
> Project: Commons Logging
> Issue Type: Bug
> Affects Versions: 1.1.1
> Environment: Java 1.5, Windows
> Reporter: Nitzan Niv
> Attachments: BugDeadlock.java, Patch-WeakHashtable-1.1.1.txt
>
>
> Reached a deadlock inside common-logging while concurrently re-deploying 2
> WARs.
> In each WAR there is an attempt to get a logger:
> private final Log logger = LogFactory.getLog(ContextLoader.class);
> Thread dump:
> [deadlocked thread] Thread-96:
> -----------------------------
> Thread 'Thread-96' is waiting to acquire lock
> 'java.lang.ref.ReferenceQueue@5266e0' that is held by thread 'Thread-102'
> Stack trace:
> ------------
>
> org.apache.commons.logging.impl.WeakHashtable.purge(WeakHashtable.java:323)
>
> org.apache.commons.logging.impl.WeakHashtable.rehash(WeakHashtable.java:312)
> java.util.Hashtable.put(Hashtable.java:414)
>
> org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:242)
>
> org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004)
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657)
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
>
> org.springframework.web.context.ContextLoader.<init>(ContextLoader.java:145)
>
> [deadlocked thread] Thread-102:
> ------------------------------
> Thread 'Thread-102' is waiting to acquire lock
> 'org.apache.commons.logging.impl.
> WeakHashtable@1e02138' that is held by thread 'Thread-96'
> Stack trace:
> ------------
> java.util.Hashtable.remove(Hashtable.java:437)
>
> org.apache.commons.logging.impl.WeakHashtable.purgeOne(WeakHashtable.java:338)
>
> org.apache.commons.logging.impl.WeakHashtable.put(WeakHashtable.java:238)
>
> org.apache.commons.logging.LogFactory.cacheFactory(LogFactory.java:1004)
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:657)
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
>
> org.springframework.web.context.ContextLoader.<init>(ContextLoader.java:145)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
