Closed mhalbritter closed 1 month ago
I think I would ask the question why would one want to use virtual threads for metrics publishing (registry).
Publishing is happening on a single blocking thread (there is another one that does some non-blocking work). They do their job very infrequently (once per minute by default) so I think the registry would not really get any benefits from using virtual threads. But we might(?) get a (probably negligible) drawback: the two infrequent virtual threads would be mounted to the same platform thread pool where other (business logic) virtual threads are, kind of "competing" with them so the business logic might be ever so slightly more disrupted in that case (I'm not sure this is measurable though).
I think that one of the expected characteristics of a virtual threads setups is memory consumption: the app only needs platform threads and does not consume more memory with additional threads pools.
As for the drawback you've highlighted I think it's quite positive actually. The virtual threads scheduler is very efficient and competing there should not be a problem as long as work is mostly I/O based.
So, 👍 from my side for this change.
Superseded by https://github.com/spring-projects/spring-boot/pull/42407.
It's possible to pass a
ThreadFactory
into theOtlpMeterRegistry
constructor. At the moment we don't do this, which then uses a platform thread based factory.We could enable virtual threads by passing factory which creates virtual threads.