It's a little akward to use different SchedulerServices with InMemoryTimeoutManager
leozilla opened this issue · 2 comments
The default InMemoryTimeoutManager uses a Scheduler with a thread pool size of 50 which is really just waaaay to big.
Timeout handlers/callbacks should be fast and non-blocking and therefore a single thread is sufficient. Multiple threads would only be necessary if the next scheduled timeout callback already needs to be executed but the scheduler thread is still busy executing the previous timeout callback. If you run in this situation than something is wrong with your timeout callbacks.
The issues itself is about the fact that one must subclass the InMemoryTimeoutManager and cannot just plugin/inject a different implementation which would be nicer from a configuration standpoint.
Maybe you can provide a way to explicitly define an SchedulerService instance in the ModuleBuilder which is used for timeout scheduling.
As for all of my issues I would like to provide a pull request but first I am waiting for your opinion and also I have very little time for doing this now unfortunately.
The timeout manager implementation can already be configured. One can always write an own implementation of the timeout manager interface. The provided one is itself very small with 160 lines including all comments and copyright header.
Having not only the TimeoutManager interface but the provided InMemoryTimeoutManager itself configurable seems overkill to me.
Implemented with v2.0.0. Reduced number of default to 2, and there's a new ctor with the expected thread number as argument.