ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Balkir (JIRA)" <j...@apache.org>
Subject [jira] [Created] (OFBIZ-9693) [FB] Package org.apache.ofbiz.service.semaphore
Date Fri, 08 Sep 2017 12:06:00 GMT
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)

Mime
View raw message