is it code related? the server is pretty simple like below.
public class EchoServer {
private final int port;
EventLoopGroup serverEventLoop = new NioEventLoopGroup(1);
EventLoopGroup btsEventLoop = new NioEventLoopGroup();
public EchoServer(int port) {
this.port = port;
}
public static void main(String[] args)
throws Exception {
int port = Integer.parseInt(args[0]);
int backlog = Integer.parseInt(args[1]);
new EchoServer(port).start(backlog);
}
public void start(int backlog) throws Exception {
final EchoServerHandler serverHandler = new EchoServerHandler();
try {
ServerBootstrap b = new ServerBootstrap();
b.group(serverEventLoop, btsEventLoop)
.channel(NioServerSocketChannel.class)
.localAddress(new InetSocketAddress(port))
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
public void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(serverHandler);
}
})
.option(ChannelOption.SO_BACKLOG, backlog)
// .option(ChannelOption.AUTO_READ, false)
.childOption(ChannelOption.SO_KEEPALIVE, true);
ChannelFuture f = b.bind().sync();
System.out.println("backlog: " +
b.config().options().get(ChannelOption.SO_BACKLOG));
// System.out.println("autoRead: " +
b.config().options().get(ChannelOption.AUTO_READ));
System.out.println("Server started and listening for connections on " +
f.channel().localAddress());
f.channel().closeFuture().sync();
} finally {
serverEventLoop.shutdownGracefully().sync();
btsEventLoop.shutdownGracefully().sync();
System.out.println("finished...");
}
}
}
public class EchoServerHandler extends ChannelInboundHandlerAdapter {
private static volatile int channelNum;
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf in = (ByteBuf) msg;
System.out.println(
"Server received: " + in.toString(CharsetUtil.UTF_8));
ctx.write(Unpooled.copiedBuffer("msg from server: " +
ctx.channel().remoteAddress(), CharsetUtil.UTF_8));
}
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
channelNum++;
System.out.println("Active Channel..." + channelNum);
}
@Override
public void channelRegistered(ChannelHandlerContext ctx) throws Exception {
// System.out.println("Register...");
}
@Override
public void channelReadComplete(ChannelHandlerContext ctx)
throws Exception {
ctx.writeAndFlush(Unpooled.EMPTY_BUFFER)
.addListener(ChannelFutureListener.CLOSE);
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx,
Throwable cause) {
cause.printStackTrace();
ctx.close();
}
}
On Thursday, July 20, 2017 at 4:43:06 PM UTC+8, Norman Maurer wrote:
>
> Like I said you may just block the EventLoop. Attach profiler and check if
> the EventLoop is blocked that is used by the SocketChannel.
>
>
> On 20. Jul 2017, at 10:42, Ronggen Liu <[email protected] <javascript:>>
> wrote:
>
> Thanks, but I'm still confused why the server can't accept the connection
> when the TCP 3-way handshake is completed.
>
> On Thursday, July 20, 2017 at 4:12:31 PM UTC+8, Norman Maurer wrote:
>>
>> Hey,
>>
>> comments inside…
>>
>> On 20. Jul 2017, at 08:50, Ronggen Liu <[email protected]> wrote:
>>
>> Hello,
>>
>> *problem*:
>> some connections were lost when there are too many clients were trying to
>> connect to the server during a short time, for example, send out about 10k
>> connections during about 3 seconds.
>>
>> *findings:*
>> as i know, all the connections would be accepted in method doReadMessage of
>> NioServerSocketChannel, and, in fact, we did find out that some
>> connections were not accepted from there, but, actually, the TCP have been
>> created successfully with completed 3-ways handsharke.
>> meanwhile, we found, to some degree, we can avoid this issue by
>> increasing the option SO_BACKLOG of ChannelOption, currently, we set it
>> with 8, should be a little bit low.
>>
>>
>> 8 is most likely a way too low. I would not touch this setting at all if
>> you not want to increase it to a high-number.
>>
>>
>>
>> *questions:*
>> how to handle this issue? as i know, the client should receive connection
>> refused error when the number of the connections exceed the SO_BACKLOG, but
>> the client didn't receive it.
>>
>>
>> No it will not receive a connect refused error but the connection will
>> just timeout. You should check if you block the EventLoop somehow and so
>> not be able to accept fast enough.
>>
>>
>>
>> Thanks,
>> Gary
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Netty discussions" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/netty/3f5aae56-1fd6-4e0b-8a6e-cfed66653c1e%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/netty/3f5aae56-1fd6-4e0b-8a6e-cfed66653c1e%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Netty discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/netty/bbccbf19-aa67-4346-83dd-566257893296%40googlegroups.com
>
> <https://groups.google.com/d/msgid/netty/bbccbf19-aa67-4346-83dd-566257893296%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/netty/e47d138c-a188-41fd-862d-868d63f0bcbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
