You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Dennis Balkir (JIRA)" <ji...@apache.org> on 2017/09/08 12:06:00 UTC

[jira] [Created] (OFBIZ-9693) [FB] Package org.apache.ofbiz.service.semaphore

Dennis Balkir created OFBIZ-9693:
------------------------------------

             Summary: [FB] Package org.apache.ofbiz.service.semaphore
                 Key: OFBIZ-9693
                 URL: https://issues.apache.org/jira/browse/OFBIZ-9693
             Project: OFBiz
          Issue Type: Sub-task
          Components: framework
            Reporter: Dennis Balkir
            Priority: Minor


- ServiceSemaphore.java:77, IS2_INCONSISTENT_SYNC
IS: Inconsistent synchronization of org.apache.ofbiz.service.semaphore.ServiceSemaphore.lock; locked 40% of time

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,
The class is not annotated as javax.annotation.concurrent.NotThreadSafe,
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.

- ServiceSemaphore.java:176, UC_USELESS_CONDITION
Condition has no effect

This condition always produces the same result as the value of the involved variable was narrowed before. Probably something else was meant or condition can be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)