Azure
[QUERY] ServiceBusClientBuilder - Why is it not possible to set an explicit Scheduler thread
Query/Question We use the ServiceBusProcessorClientBuilder to build our subscription clients for processing Azure Messages. Would it be possible to set a scheduler thread in the ServiceBusProcessorClientBuilder? Now the Schedulers.boundedElastic() is set by default but can not be set because it is package protected. I think there's a reason for that - can you explain why?
Why is this not a Bug or a feature Request? Before requesting a feature i want to understand why the default reacor thread might be mandatory
Setup (please complete the following information if applicable):
- OS: Windows 10
- IDE: IntelliJ
- Library/Libraries: com.azure:azure-sdk-bom:1.2.15
Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
- [ x] Query Added
- [ x] Setup information Added
One example where we had faced issues with this is in one of our applications we had knowingly longer processing messages, Over time the amount of messages increased and eventually we reached the 20 real parallel messages we had configured as maximum. What surprised us what that suddenly Kubernetes that was calling the actuator/health/readiness endpoint would start to set the application offline because it was no longer responding in the 5 second timeouts. After some debugging we eventually found that because we are using spring-session-redis we also automatically got the ReaxctiveRedisHealthIndicator enabled that would check if Redis is reachable. Because reactor by default is using a single central threadpool - the "boundedElastic" this one was shared for our message processing and also this Redis Health check. And actually pretty much by chance we had parallel set to 20 and our application was running 2 CPUs and the Reactor code is
Optional.ofNullable(System.getProperty("reactor.schedulers.defaultBoundedElasticSize"))
.map(Integer::parseInt)
.orElseGet(() -> 10 * Runtime.getRuntime().availableProcessors());
so more or less by chance it was actually 20 threads which matched our degree of expected parallel processing. However once our message load reached a level were actually 20 threads were processing longer running messages at the same time the health indicator was waiting for a thread in the Mono.block() call and would eventually give up on getting a result and timeout.
Imo this is both not very transparent and also pretty risky to forcefully rely on the default Reactor Scheduler pool in the whole messaging library and not even provide a well documented option to set a dedicated scheduler just for azure message processing in the builder. We'd also really like to see this option enabled unless there are big reasons not to do so.
Moving this to backlog. In the meantime, updating documentation to explain how the concurrency and shared thread pool sizing are related - Troubleshoot Azure Service Bus - Azure SDK for Java | Microsoft Learn
