Static Code Review: Inconsistent synchronization of org.sakaiproject.event.impl.NotificationCache.m_holdEventProcessing; locked 66% of time
Description
Activity
Jean-François Lévêque January 29, 2010 at 1:55 AM
Assigning with Automatic. If this gets to the wrong person, please update JIRA configuration for Event service and assign to the right person.
Lance Speelmon January 28, 2010 at 11:10 AM
It was never completely clear to me how to resolve this issue. It probably still needs investigation. Thanks, L
Peter Knoop March 2, 2009 at 9:34 AM
[Bulk Comment] This is issue is currently scheduled to be resolved for inclusion in the Sakai 2.6.0 release, however, it is still unresolved. If you still planning on resolving it, please reply with a comment indicating when you expect to have it resolved. If you don't think you will be able to address this issue in time for the release, please reply with a comment indicating such; particularly if this issue is Blocker or Critical priority. If the resolution of this issue is to be delayed until a future release (i.e., 2.7), then please update the Fix Version accordingly.
Lance Speelmon November 13, 2008 at 6:29 AM
I am reopening - It is not clear to me how to resolve the issue. L
Jean-François Lévêque November 13, 2008 at 6:15 AM
From Lance's comment on 27-Feb-2008, it seems this is a Won't Fix. The code review still reports the problem. Could you update the Resolution, Lance?
Details
Priority
MajorAffects versions
Components
Assignee
UnassignedUnassignedReporter
Lance SpeelmonLance Speelmon
Details
Details
Priority
Major
See: http://qa1-nl.sakaiproject.org/codereview/bug_dashboard/findbugs_MT_CORRECTNESS.html
Inconsistent synchronization of org.sakaiproject.event.impl.NotificationCache.m_holdEventProcessing; locked 66% of time
IS: Inconsistent synchronization (IS2_INCONSISTENT_SYNC)
The fields of this class appear to be accessed inconsistently with respect to synchronization. This bug report indicates that the bug pattern detector judged that
The class contains a mix of locked and unlocked accesses,
At least one locked access was performed by one of the class's own methods, and
The number of unsynchronized field accesses (reads and writes) was no more than one third of all accesses, with writes being weighed twice as high as reads
A typical bug matching this bug pattern is forgetting to synchronize one of the methods in a class that is intended to be thread-safe.
You can select the nodes labeled "Unsynchronized access" to show the code locations where the detector believed that a field was accessed without synchronization.
Note that there are various sources of inaccuracy in this detector; for example, the detector cannot statically detect all situations in which a lock is held. Also, even when the detector is accurate in distinguishing locked vs. unlocked accesses, the code in question may still be correct.
This description refers to the "IS2" version of the pattern detector, which has more accurate ways of detecting locked vs. unlocked accesses than the older "IS" detector.