jbertram commented on PR #6202: URL: https://github.com/apache/artemis/pull/6202#issuecomment-3826236633
> Garys idea seems reasonable... Agreed. I implemented his suggestion. > ...I also dont actually know that we really want this set to 0 all the time in the test suite? I don't know if we do or not. There's not much detail on https://issues.apache.org/jira/browse/ARTEMIS-2428 where this change originated. > Until yesterday the related bit previously waited for as long as needed during the entire test suite... The problem, as outlined on the Jira, is that the call to `awaitUninterruptibly()` can apparently hang forever so a timeout is needed for these calls. Rather than create and document a new parameter I simply re-used the existing, but undocumented, `shutdownTimeout` parameter. I certainly could create a new parameter specifically for closing the Netty `ChannelGroup` instances. I could name it something like `channelGroupShutdownTimeout`, but then that would introduce a naming asymmetry with `shutdownTimeout` which is specifically aimed at the Netty `EventLoopGroup` instance. Since `shutdownTimeout` was undocumented I could potentially just rename it to `eventLoopGroupShutdownTimeout` and then document both new parameters, hoping that nobody was actually using `shutdownTimeout`, or I could deprecate `shutdownTimeout` and let it live alongside the new parameter. I'd probably need to do the same with `quietPeriod` as well. Ultimately we just need a timeout here so these calls can't hang indefinitely. Using `shutdownTimeout` seems the simplest path forward to me. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
