Schedulers shutdown capability. #1769
Conversation
There was a problem hiding this comment.
I don't like putting a synchronized block in the line of fire on something like this that doesn't need to be.
This is a global lock and exactly the type of stuff I find in our production environments.
There was a problem hiding this comment.
Of course we can do shutdown without this, but then the schedulers are dead and without app restrart, they won't come back.
There was a problem hiding this comment.
Not to mention, they can't be tested because they shutdown the global threads for good.
Schedulers.io() cost only a volatile read and doesn't block concurrent calls unnecessary.
There was a problem hiding this comment.
Could we have some javadoc on this method about if this method is synchronous or asynchronous? If it's not synchronous then how will I know when the Scheduler has shutdown, that is when the running threads currently associated with the Scheduler have completed?
There was a problem hiding this comment.
This is not detailed in the requirements, but the implementation basically calls unsubscribe() and shutdownNow() which generally do best effort to terminate outstanding work. So it is quite possible an unresponsive/ignorant work may keep a worker thread operational and make Tomcat still print out the leak notification.
Is the underlying issue still relevant (almost a month passed with no feedback)?
3 participants
Proposal for shutting down the computation and io schedulers on demand.
#1730