There is a race condition in LocalLockMergingSegmentReadLocker which can lead to more calls delete on the underlying DistributedSegmentReadLocker which results in the file being removed from the caches.

This happens with three or more threads acquiring and releasing locks on the same file simultaneously:

1. Thread 1 (T1) acquires a lock and creates a LocalReadLock, call it L1 - the underlying lock is acquired
2. T2 starts to acquire and holds a reference to L1
3. T3 starts to acquire and holds a reference to L1
4. T1 releases - L1 at this stage only has value of 1 - so the underlying lock is released, and L1 is removed from the map
5. T2 continues - finds L1 with value 0 and acquires the underlying lock
6. T3 continues - increments L1 value to 2
7. T2 releases - creates a new LocalReadLock, L2 - this has zero value so the underlying lock is released, and L2 is removed from the map
8. T3 releases - creates a new LocalReadLock, L3 - this has zero value so the underlying lock is released, and L3 is removed from the map
9. The final step triggers a real file delete as underlying lock is released one too many times