Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

should config.getThreadFactory take a pool name or suffix? #1584

Open
dsilvasc opened this issue Oct 6, 2018 · 3 comments
Open

should config.getThreadFactory take a pool name or suffix? #1584

dsilvasc opened this issue Oct 6, 2018 · 3 comments

Comments

@dsilvasc
Copy link

dsilvasc commented Oct 6, 2018

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?

@slandelle
Copy link
Contributor

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.

@mchernyakov
Copy link

Hi @slandelle, is it still actual? I would like to take it.

@slandelle
Copy link
Contributor

Hi @mchernyakov
Yes, feature request is still open, please feel free to contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants