[
https://issues.apache.org/jira/browse/OFBIZ-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202753#comment-16202753
]
Michael Brohl commented on OFBIZ-9693:
--------------------------------------
Hi Dennis,
the tests are failing after applying this patch, please check.
Thanks,
Michael
> [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
> Assignee: Michael Brohl
> Priority: Minor
> Attachments:
> OFBIZ-9693_org.apache.ofbiz.service.semaphore_bugfixes.patch
>
>
> - 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)
