We've got two places now:
CodecRegistrationCheckerCompilerPlugin#initSerializerCheckCompilerPluginComponent...#interactWithTheCacheFile
where there's pessimistic locking (java.nio.channels.FileChannel#lock(), introduced on #131) wrapped into optimistic locking (retry on OverlappingFileLockException, first introduced on #218 and then by myself on #310).
The need for retry on OverlappingFileLockException clearly indicates that FileChannel#lock() doesn't fulfil its purpose. Let's figure out a proper solution for the problem. Probably the easiest approach would be not to use filesystem locks at all, just application-level locks within codec-registration-checker-compiler-plugin itself instead. Still, if it's possible to achieve pessimistic locking on filesystem, that's probably the cleanest solution.
I'd suggest doing a research/comparing viable options on a separate sandbox project, unrelated to ASH, and only then updating CodecRegistrationCheckerCompilerPlugin and SerializerCheckCompilerPluginComponent.
We've got two places now:
CodecRegistrationCheckerCompilerPlugin#initSerializerCheckCompilerPluginComponent...#interactWithTheCacheFilewhere there's pessimistic locking (
java.nio.channels.FileChannel#lock(), introduced on #131) wrapped into optimistic locking (retry onOverlappingFileLockException, first introduced on #218 and then by myself on #310).The need for retry on
OverlappingFileLockExceptionclearly indicates thatFileChannel#lock()doesn't fulfil its purpose. Let's figure out a proper solution for the problem. Probably the easiest approach would be not to use filesystem locks at all, just application-level locks within codec-registration-checker-compiler-plugin itself instead. Still, if it's possible to achieve pessimistic locking on filesystem, that's probably the cleanest solution.I'd suggest doing a research/comparing viable options on a separate sandbox project, unrelated to ASH, and only then updating
CodecRegistrationCheckerCompilerPluginandSerializerCheckCompilerPluginComponent.