[Proposal] Support for requesting dedicated thread pool for concurrent message pumping in Non-Session Processor instances

[anuchandy]

The Non-session Processor uses the global shared Reactor scheduler to pump messages, this is fine in most cases.

But there are cases where customers run a lot of Non-session Processors on a machine (e.g. 50 clients) and in such cases all Processor instances share global shared pool scoped to JVM. This creates challenges for users because –

1. users need to configure this global shared thread pool size using Reactor specific env var to accommodate for all processor instances need,
2. users need to also scan through application and third-party components (e.g. Spring) to see if those also uses this shared global pool. If they do, such uses must be considered as well when sizing the pool.

If we look at the Session Processor, this is not an issue as each session internally gets its own dedicated pool, and session processor never used global thread pool.

This is a proposal to allow users to request dedicated thread pool for each Non session Processor instance. Library can internally manage this pool similarly to how it is done in the session case. This could be achieved by adding an overload for maxConcurrentCalls(..) in Non session Processor builder -

maxConcurrentCalls(int:concurrency, bool:useDedicatedThreadPool)

For most of the users, this suffices their need and is simple – it hides the internals of pool, and the library manages the lifetime and cleaning up of the pool, aligns with how pools are managed in session processor.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

com.azure:azure-messaging-servicebus