Potential blocking calls not wrapped in blocking
froth opened this issue · comments
I don't have hard proof for this, but from my understanding several calls to micrometer contain locks and should be wrapped in blocking instead of delay.
This delay calls after some indirection the following method in micrometer:
https://github.com/micrometer-metrics/micrometer/blob/54f89f40743937a5a78fb57eb0ddb6b2e6238be4/micrometer-core/src/main/java/io/micrometer/core/instrument/MeterRegistry.java#L598
This contains a synchronized block over meterMapLock and can block the current thread. Therefore I would argue that this could lead to blocking one of the io-compute threads if several calls hit the lock in parallel.
That's a great point, thanks for reporting. Would you be prepared to author a PR to fix this?
Sure, can do so. Most likely at some point next week, this week is kind of a mess ;)
I opened a pull request. I tried to be as thorough as I could in searching for other locks in the micrometer implementation. These were all the clear blocking cases I found. But I might have missed something.
The only other thing I found is that AtomicInteger (used in gauge) is not strictly guaranteed to be non blocking. This depends on the underlying processor architecture. However on x86 / x86_64 it behaves in a non blocking way. I did a quick search for arm but did not find clear information. I decided to leave AtomicInteger alone for now(my code runs on x86_64 anyways). But maybe someone else wants to take a deeper look.