Summary: | Synchronize possible concurrent accesses to field "org.apache.catalina.tribes.transport.bio.util.FastQueue.checkLock". | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Mohsen Vakilian <reprogrammer> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | reprogrammer |
Priority: | P2 | ||
Version: | trunk | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux |
Description
Mohsen Vakilian
2011-12-18 23:34:54 UTC
That is all essentially debug code. The setter may be accessed via reflection when server.xml is parsed by I haven't checked if it is exposed. I suspect that it is not exposed and that it is just changed in the source when debugging issues. I'm not concerned about concurrent access but to be on the safe side it should probably be volatile. The flags it then uses to track status during debugging should be certainly be volatile. Fixed in trunk and 7.0.x and will be included in 7.0.24 onwards. Thanks for resolving this issue. Keshmesh <http://keshmesh.cs.illinois.edu/> detected this problem when we ran it on Tomcat using method "org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.run()" as an entry point. (In reply to comment #2) > Fixed in trunk and 7.0.x and will be included in 7.0.24 onwards. When I wrote that queue at the end of 2004 using some hand made asymmetric locks I added the checkLock flag to be able to debug in case the lock constructs would turn out to be buggy. Now, 7 years later, ans after only very few changes to that code, I think we actually no longer need "checkLock" and the flags only neded in combination with checkLock, i.e. inAdd, inRemove, inMutex. IMHO we can remove that part. You know me, always happy to delete code :) Mark |