You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both DefaultAsyncHttpClient and ChannelManager call config.getThreadFactory, but when the result is null, DefaultAsyncHttpClient instantiates a DefaultThreadFactory with the pool name config.getThreadPoolName() + "-timer" while ChannelManager instantiates that same factory with the pool name config.getThreadPoolName().
This means that when you don't set a thread factory in the client config, you'll end up with two different pool names, but if you do set a thread factory in the client config, you'll end up with the same pool name for both use cases.
Should getThreadFactory take a pool name (or even just a suffix) to allow differentiating its use cases in DefaultAsyncHttpClient and ChannelManager?
The text was updated successfully, but these errors were encountered:
There's value in naming the (single) timer thread differently so it can be told appart from the IO threads.
AFAIK, the only way to achieve the same thing would be to have 2 different ThreadFactories.
Contributions welcome.
Both
DefaultAsyncHttpClient
andChannelManager
callconfig.getThreadFactory
, but when the result is null,DefaultAsyncHttpClient
instantiates aDefaultThreadFactory
with the pool nameconfig.getThreadPoolName() + "-timer"
whileChannelManager
instantiates that same factory with the pool nameconfig.getThreadPoolName()
.This means that when you don't set a thread factory in the client config, you'll end up with two different pool names, but if you do set a thread factory in the client config, you'll end up with the same pool name for both use cases.
Should
getThreadFactory
take a pool name (or even just a suffix) to allow differentiating its use cases inDefaultAsyncHttpClient
andChannelManager
?The text was updated successfully, but these errors were encountered: