Refactoring ServiceSemaphore (OFBIZ-11204)

[Gil Portenseigne <gi...@nereide.fr>]

Hello,

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.

Regards,

Gil

Re: Refactoring ServiceSemaphore (OFBIZ-11204)

[Mathieu Lirzin <ma...@nereide.fr>]

Hello Gil,

Gil Portenseigne <gi...@nereide.fr> 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