I am writing to report a race issue on use of ConcurrentHashMap. The issue is reported by our tool in an automatic way. Although manually confirmed, it would be a false positive, given we do not know the specification of the program. We would very appreciate if you could check below for details and confirm with us whether it is a real problem. For more information, please refer to our website: http://sav.sutd.edu.sg/?page_id=2845
File: geoserver/geoserver/src/extension/control-flow/src/main/java/org/geoserver/flow/controller/RateFlowController.java Location: Line (173, 223) Description: The get-put operations in the synchronized block (from line 169 to line 175) guarded by lock "userKey" may interleave with the get-remove operations synchronized block (from line 217 to line 231) guarded by lock "pipelines" since they are guarded by different locks. Thus the atomicity of the get-put operation may be broken by the remove operation in line 223.
File: geoserver/geoserver/src/extension/control-flow/src/main/java/org/geoserver/flow/controller/RateFlowController.java Location: Line (74/71,87) Description: Same as above.
Environment
None
Activity
Andrea Aime
February 15, 2017 at 11:46 AM
Mass closing all resolved issues not modified in the last 4 weeks
Andrea Aime
March 6, 2016 at 1:53 PM
In this case it might happen that two counter objects get associated to the same ip/user, in case a removal happens after the first put. This does not seem possible as the counters would be both new, and the counters are not checked for removal for at least 200 time intervals. So while formally there is a concurrency issue, in practice there is no issue, and a formal removal of the issue would cause severe contention issues at runtime in the first guarded lock (as to solve it, we'd have to lock on counters in both cases, locking on userkey is not an option for the second operation, which is a global cleanup).
Andrea Aime
September 26, 2015 at 9:28 AM
Hi, the ticketing system is not the right place to ask questions, please open tickets only if you have confirmation and steps to reproduce for a specific bug.
Medium
Hi, Developers of geoserver/geoserver,
I am writing to report a race issue on use of ConcurrentHashMap. The issue is reported by our tool in an automatic way. Although manually confirmed, it would be a false positive, given we do not know the specification of the program. We would very appreciate if you could check below for details and confirm with us whether it is a real problem. For more information, please refer to our website: http://sav.sutd.edu.sg/?page_id=2845
File: geoserver/geoserver/src/extension/control-flow/src/main/java/org/geoserver/flow/controller/RateFlowController.java
Location: Line (173, 223)
Description:
The get-put operations in the synchronized block (from line 169 to line 175) guarded by lock "userKey" may interleave with the get-remove operations synchronized block (from line 217 to line 231) guarded by lock "pipelines" since they are guarded by different locks. Thus the atomicity of the get-put operation may be broken by the remove operation in line 223.
File: geoserver/geoserver/src/extension/control-flow/src/main/java/org/geoserver/flow/controller/RateFlowController.java
Location: Line (74/71,87)
Description:
Same as above.