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
Blocking in SelectorProvider#provider #2308
Comments
normanmaurer
pushed a commit
that referenced
this issue
Mar 13, 2014
…ve condition when create new NIO channels. Motivation: At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which uses synchronized internal. This change removed the bottleneck. Modifications: Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation. Result: Less conditions when create new channels.
normanmaurer
pushed a commit
that referenced
this issue
Mar 13, 2014
…ve condition when create new NIO channels. Motivation: At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which uses synchronized internal. This change removed the bottleneck. Modifications: Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation. Result: Less conditions when create new channels.
normanmaurer
pushed a commit
that referenced
this issue
Mar 13, 2014
…ve condition when create new NIO channels. Motivation: At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which uses synchronized internal. This change removed the bottleneck. Modifications: Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation. Result: Less conditions when create new channels.
哇 |
漂亮! |
pulllock
pushed a commit
to pulllock/netty
that referenced
this issue
Oct 19, 2023
… remove condition when create new NIO channels. Motivation: At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which uses synchronized internal. This change removed the bottleneck. Modifications: Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation. Result: Less conditions when create new channels.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently
SelectorProvider#provider
(which contains synchronized block) called for every new channel creation. This can can cause unnecessary blocking when application creates a lot of connection (performance penalty about 1% when creating 5000 connections/second).Possible solution is to store result of
#provider
and calljava.nio.channels.spi.SelectorProvider#openSocketChannel
directly, withoutSocketChannel#open
.The text was updated successfully, but these errors were encountered: