tree 702b33dd2c5e49e73251d6ac55090d7dffbe3844
parent aa8125a4aa6375a57a7e5422df842eada784a9ae
author Luca Milanesio <luca.milanesio@gmail.com> 1607962217 +0000
committer Luca Milanesio <luca.milanesio@gmail.com> 1608243793 +0000

Fix indexing locks on the sender side

Replace locks with semaphores when blocking multiple
operations on the sender side for the same index name + id.

Using native locks would require to have exactly
the same thread holding the lock, which may or may not
be the case for forwarding a remote indexing operation.

When running a remote indexing, the operation may be
retried multiple times in different threads, hence the use
of a Semaphore instead of a Lock is more appropriate.
When remote indexing is not retried, the execution is
delegated to a REST forwarder executor that makes the remote
invocation and returns the result in a different thread,
failing to release the lock.

The failure to release the lock is not detected because
the execution is swallowed by the lambda: the situation isn't
immediately critical, because *IF* there is no huge load
of changes coming through, the next invocation may land on the
same thread. However, if that doesn't happen because of
parallel load using more threads, the JVM ends up in deadlock.

Semaphores do not require to be acquired and released by
the same threads and would functionally perform the same
type of exclusive "logical locking" for preventing the
concurrent reindexing of the same entity.

Bug: Issue 13824
Change-Id: I39484b0d0cdf21d60bf334d1d1fa90f07ea28bba