Incorrect socket close

[Богдан Бедный]

Hello, group.

I`m write http server on netty, and i`ve got a problem. After send a response on request, I add chanel close listener (addListener(ChannelFutureListener.CLOSE)). 

But instead of closing (FIN_WAIT), the socket status becomes TIME_WAIT and closes after 2 minutes (standart time on Windows).

I tried to pick up various options, but it did not help.

How to fix it?

p.s. options that I have changed

option(ChannelOption.TCP_NODELAY, true)

option(ChannelOption.SO_KEEPALIVE, false)

option(ChannelOption.SO_REUSEADDR, false)

childOption(ChannelOption.TCP_NODELAY, true)

childOption(ChannelOption.SO_KEEPALIVE, false)

childOption(ChannelOption.SO_REUSEADDR, false)

[Norman Maurer]

To prevent TIME_WAIT you would use:

childOption(ChannelOption.SO_REUSEADDR, true)

Bye,

Norman

-- 
Norman Maurer

--
 
---
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 netty+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Богдан Бедный]

Don`t work :( 

[Богдан Бедный]

I`m using 4.0.13 version. It maybe a problem? 

[Norman Maurer]

Could you show us your complete code ?

-- 
Norman Maurer

nma...@redhat.com

JBoss, by Red Hat

An 29. Januar 2014 at 09:24:49, Богдан Бедный (oneass...@gmail.com) schrieb:

Don`t work :( 

--
 
---
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 netty+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

---

- screenshot.png, 3 KB

[Богдан Бедный]

Server run: 

final EventLoopGroup bossGroup = new NioEventLoopGroup();

final EventLoopGroup workerGroup = new NioEventLoopGroup();

try {

    final ServerBootstrap b = new ServerBootstrap();

    b.group(bossGroup, workerGroup)

    .channel(NioServerSocketChannel.class)

    .childOption(ChannelOption.SO_REUSEADDR, true);

    if (Config.DEBUG) {

        b.option(ChannelOption.SO_BACKLOG, 100)

        .handler(new LoggingHandler(LogLevel.INFO))

        .childHandler(new HttpUniversityInitializer());

    } else {

        b.childHandler(new HttpUniversityInitializer());

    }

    final Channel ch = b.bind(Config.PORT).sync().channel();

    ch.closeFuture().sync();

} finally {

    bossGroup.shutdownGracefully();

    workerGroup.shutdownGracefully();

}

[Norman Maurer]

Can you also show the all the code of the  ChannelHandlers that HttpUniversityInitializer add to the ChannelPipeline

-- 
Norman Maurer

nma...@redhat.com

JBoss, by Red Hat

An 30. Januar 2014 at 18:40:32, Богдан Бедный (oneass...@gmail.com) schrieb:

HttpUniversityInitializer

[Богдан Бедный]

Yes, of course

HttpUniversityInitializer

@Override

protected void initChannel(SocketChannel ch) throws Exception {

    ChannelPipeline pipeline = ch.pipeline();

    if (Config.SSL) {

        SSLEngine engine =

            SecureChatSslContextFactory.getClientContext().createSSLEngine();

        engine.setUseClientMode(false);

        pipeline.addLast("ssl", new SslHandler(engine));

    }

    if (Config.GZip) {

        pipeline.addLast("inflater", new HttpContentDecompressor());

        pipeline.addLast("deflater", new HttpContentCompressor());

    }

    pipeline.addLast("decoder", new HttpRequestDecoder());

    pipeline.addLast("encoder", new HttpResponseEncoder());

    pipeline.addLast("handler", new HttpUniversityHandler());

}

HttpUniversityHandler

private final FullHttpResponse httpResponse = new DefaultFullHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.OK);

@Override

protected void channelRead0(final ChannelHandlerContext ctx, final HttpObject httpObject) throws Exception {

    if (httpObject instanceof HttpRequest) {

        final HttpRequest httpRequest = (HttpRequest) httpObject;

        if (httpRequest.getMethod() != HttpMethod.GET && httpRequest.getMethod() != HttpMethod.PUT

                && httpRequest.getMethod() != HttpMethod.POST) {

            Error.send501NotImplemented(ctx);

            return;

        }

        HttpHeaders.setHeader(httpResponse, HttpHeaders.Names.CONTENT_TYPE, "application/json");

        HttpHeaders.setKeepAlive(httpResponse, false);

        HttpHeaders.setDate(httpResponse, new Date());

        HttpHeaders.setHeader(httpResponse, HttpHeaders.Names.ACCEPT, HttpMethod.GET + " " + HttpMethod.POST + " " + HttpMethod.PUT);

        if (Config.GZip) {

            HttpHeaders.setHeader(httpResponse, HttpHeaders.Names.ACCEPT_ENCODING, HttpHeaders.Values.GZIP);

        }

    }

    if (httpObject instanceof LastHttpContent) {

        final LastHttpContent httpContent = (LastHttpContent) httpObject;

        if (httpContent.content().isReadable()) {

            HttpHeaders.setContentLength(httpResponse, httpContent.content().readableBytes());

            httpResponse.content().writeBytes(httpContent.content());

        }

        ctx.channel().writeAndFlush(httpResponse).addListener(ChannelFutureListener.CLOSE);

    }

}

["이희승 (Trustin Lee)"]

TIME_WAIT state appears on the side where the socket close() was initiated.  If your client closes the socket, your client will have TIME_WAIT.  Because your server closed the socket, your server will see a lot of TIME_WAIT states in netstat, and it is expected.

How do we handle this problem?  In the environment you have control over the behavior of clients, you let the clients close the connection.  However, it is practically impossible in many cases, so you have to tweak your OS parameters.

In Linux, you have various parameters such as:

  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
  /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
  /proc/sys/net/ipv4/tcp_tw_reuse
  /proc/sys/net/ipv4/tcp_tw_recycle

Note some parameters are only available in a certain Linux kernel version (or above).  I'm not sure about Windows, but I should have something similar.

HTH,
T

--
 
---
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 netty+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
https://twitter.com/trustin
https://twitter.com/trustin_ko
https://twitter.com/netty_project