Hello Gil,
Gil Portenseigne <
[hidden email]> writes:
> In one of our customer project, where we are using multiple OFBiz
> instances to run backend jobs, in which some are using service semaphore
> system.
>
> While these semaphore jobs are run quite intensively by several OFBiz
> process, we stumble upon a lot of 'Error' logs that are polluting other
> production log, in the fact that these are not really error, but a
> failure trying to insert a lock into ServiceSemaphore table, that leads
> to another waiting loop.
>
> I then proposed a refactoring of the implementation (jira OFBIZ-11204),
> that works currently fine in our production environment.
>
> Since semaphore feature is a quite critical one, some reviews would be
> appreciated before commiting it in the codebase.
Thanks for tackling this issue and providing some documentation
I am unfamiliar with this part of the OFBiz internals and fails to
properly understand it properly after a quick glance.
The only remark I can make right right now is that the terminology used
seems confusing, which is not directly related to your patch but to the
current implementation.
A semaphore is a concurrency object/variable allowing an arbitrary
bounded number of "processors" to run concurrently in some critical
section. However the ‘ServiceSemaphore’ seems to allow only one
processor to execute a service at a time, which makes it a “Lock”
instead of a general “Semaphore”.
So this not really a priority, but it might be a good idea to later
rename this class to ‘ServiceLock’ and make it implement the
‘java.util.concurrent.locks.Lock’ interface for more
understandeable/predictable semantics.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
Locked
