Introduce necessary executors and implement sleepAsync - #3
Conversation
634c8dd to
85b1c3d
Compare
JAVA-6240
JAVA-6240
| * All {@link Throwable}s are logged.</li> | ||
| * </ul> | ||
| */ | ||
| public final class MongoThreadPoolExecutor extends ThreadPoolExecutor { |
There was a problem hiding this comment.
VAKOTODO Update the description of https://jira.mongodb.org/browse/JAVA-6109: mention that all other executor implementations / single threads should be replaces either with virtual threads (https://jira.mongodb.org/browse/JAVA-4930 - distant future), or MongoThreadPoolExecutor/MongoScheduledThreadPoolExecutor (this includes the executors created in AsynchronousTlsChannelGroup, NettyStreamFactoryFactory (NioEventLoopGroup)), unless it's an IO executor supplied by an application.
Also mention in that ticket to document that the executors supplied by applications should themselves make sure uncaught Throwables are not swallowed, potentially the same way MongoThreadPoolExecutor/MongoScheduledThreadPoolExecutor do it.
There was a problem hiding this comment.
This is about updating Jira, so not blocking merge.
So consider it resolved from standpoint of merging this PR.
| */ | ||
| StreamFactory create(SocketSettings socketSettings, SslSettings sslSettings); | ||
|
|
||
| AsyncClientExecutor getClientExecutor(); |
There was a problem hiding this comment.
VAKOTODO Try exposing only the IO executor (as Executor), and create AsyncClientExecutor outside of StreamFactoryFactory implementations.
There was a problem hiding this comment.
There was a problem hiding this comment.
VAKOTODO Analyze all lines matching catch \(.*Throwable, catch \(.*Error, to make sure that we indeed propagate Errors in a way that allows applications to handle them programmatically.
An example where we do not do that: AsynchronousTlsChannelGroup.execute.
3 participants
AI usage
AI was used only to review and to suggest ways to deal with the serious bug it discovered (see below).
AI identified a serious bug with
CommonExecutoroffloading scheduled tasks to anotherExecutor, which I failed to think about on my own. AI also expressed ideas on how one may deal with that problem. One of them I manually implemented inDefaultAsyncClientExecutor.JAVA-6240