You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2019/12/03 21:00:25 UTC

NioSelectorPool usefulness

Hi,

NioSelectorPool is probably never used out of its default default
configuration as the capability is well hidden, so I had a look. I couldn't
really see a difference with ab/h2load between the default (shared = true)
and a pooled selector with all the extra code.

Then moving down the stack NioBlockingSelector is also an experience.
"Possibly encountered sun bug 5076772 on windows JDK 1.5" might not be the
most useful debug log anymore.

Any opinion on that ?

Rémy

Re: NioSelectorPool usefulness

Posted by Rémy Maucherat <re...@apache.org>.
On Tue, Dec 3, 2019 at 11:08 PM Mark Thomas <ma...@apache.org> wrote:

> On 03/12/2019 21:00, Rémy Maucherat wrote:
> > Hi,
> >
> > NioSelectorPool is probably never used out of its default default
> > configuration as the capability is well hidden, so I had a look. I
> > couldn't really see a difference with ab/h2load between the default
> > (shared = true) and a pooled selector with all the extra code.
> >
> > Then moving down the stack NioBlockingSelector is also an experience.
> > "Possibly encountered sun bug 5076772 on windows JDK 1.5" might not be
> > the most useful debug log anymore.
> >
> > Any opinion on that ?
>
> No objections to removing the NioSelectorPool or cleaning up the
> NioBlockingSelector at some point fairly soon. However, I'm a little
> concerned about connector stability right now (see thread on asyncIO) so
> I think we should move a little more carefully on this than usual.
>

Committed for review now that 9.0.30 is tagged, since it's very easy to
revert if needed for any reason (test failures, urgent release need).

Rémy

Re: NioSelectorPool usefulness

Posted by Mark Thomas <ma...@apache.org>.
On 03/12/2019 21:00, Rémy Maucherat wrote:
> Hi,
> 
> NioSelectorPool is probably never used out of its default default
> configuration as the capability is well hidden, so I had a look. I
> couldn't really see a difference with ab/h2load between the default
> (shared = true) and a pooled selector with all the extra code.
> 
> Then moving down the stack NioBlockingSelector is also an experience.
> "Possibly encountered sun bug 5076772 on windows JDK 1.5" might not be
> the most useful debug log anymore.
> 
> Any opinion on that ?

No objections to removing the NioSelectorPool or cleaning up the
NioBlockingSelector at some point fairly soon. However, I'm a little
concerned about connector stability right now (see thread on asyncIO) so
I think we should move a little more carefully on this than usual.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org