sslhandler leaking direct buffer #5928
Labels
Comments
|
See the earlier conversation here: |
Scottmitch
added a commit
to Scottmitch/netty
that referenced
this issue
Oct 20, 2016
Motivation: 62057f7 introduced a regression where large amounts of memory could accumulate, and not be cleaned up in a timely manner. Modifications: - Call super.channelReadComplete() instead of calling ctx.fireChannelReadComplete() Result: Fixes netty#5928
|
@Scottmitch - Thanks for fixing it. @trustin @normanmaurer Referring the earlier fix, i fixed it in my local branch and tested again. I still see the leak issue. Extra info, if that could be of any pointers: #2. Also, I am using ChannelPoolMap to acquire the channels. It unusually taking long time around 20ms to acquire a channel. Not the case acquiring a channel for Netty based application. #3. In this same case SSL also takes longer and throws SSL exception nioEventLoopGroup-5-4, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack? )) Please let me know if you need more details. Here is the trace. |
|
looking more closely ... the leak trace looks similar to #5631 where the buffer is owned by the aggregator. Are you using auto read, are you applying back pressure, and does this memory get freed when the channel is closed? |
|
@Scottmitch i went back to 4.1.4.Final. the issue isn't much though. The Leak message appears very initial part of sudden high throughput. I haven't checked if the memory is freed after channel is closed. |
|
@Scottmitch verified, there's back pressure as well. |
|
@svnp10 - Please provide a reproducer, and answer the all questions above. The leak reports you provided in isolation don't provide enough context to debug this issue. |
|
@svnp10 ping |
|
When the static block for initializing the SSL in the inner class moved to the class outside the problem no longer occurred. PS - Leak report still occurred in the first GC cycle but not as bad as earlier. public class ServiceClientInitializerWithOptions {
private static final Logger LOG = LoggerFactory
.getLogger(ServiceClientInitializerWithOptions.class);
private boolean initialized;
private Bootstrap clientBootstrap;
private static final EventExecutor executor = new DefaultEventExecutorGroup(64,
new DefaultThreadFactory("OutBound-Thread")).next();
private static boolean SSLEnabled = false;
public void initialize() {
LOG.trace("ServiceClientInitializer initialize");
if (initialized)
return;
EventLoopGroup workerGroup = Epoll.isAvailable()
? new EpollEventLoopGroup(64, new DefaultThreadFactory("Client-EventLoop"))
: new NioEventLoopGroup(64, new DefaultThreadFactory("Client-EventLoop"));
clientBootstrap = new Bootstrap();
clientBootstrap.group(workerGroup)
.channel(Epoll.isAvailable() ? EpollSocketChannel.class : NioSocketChannel.class);
// .handler(new DefaultClientPipeline());
initialized = true;
LOG.trace("Client Bootstrapped");
}
public Bootstrap getClientBootstrap() {
return clientBootstrap;
}
public static class DefaultClientPipelineWithOptions extends ChannelInitializer {
private static SslContext sslContext;
static AppConfig appConfig = GatewaySpringContext.getInstance().getBean(AppConfig.class,
"appConfig");
static {
/*
* if
* (GatewaySpringContext.getInstance().getContext().getEnvironment()
* .getProperty("server.outgoing.ssl", "true").equals("true")) {
*/
if (appConfig.isServeroutgoingSsl()) {
SSLEnabled = true;
sslContext = SslUtils.initSSL(true,
SslProviderFactory.getInstance().getSslProvider());
}
}
@Override
protected void initChannel(Channel ch) throws Exception {
init(ch);
}
public static void init(Channel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
// pipeline.addFirst(executor, "flush", new
// FlushConsolidationHandler());
// pipeline.addLast(executor, "outboundTimer", new ClientOutboundTimerHandler());
if (SSLEnabled) {
SslHandler handler = sslContext.newHandler(ch.alloc());
Future<Channel> future = handler.sslCloseFuture();
future.addListener(new GenericFutureListener<Future<? super Channel>>() {
@Override
public void operationComplete(Future<? super Channel> future) throws Exception {
LOG.error("OutBound SSL Handler closed");
}
});
pipeline.addLast(executor, "SSL", handler);
}
// pipeline.addLast(new LoggingHandler(LogLevel.TRACE));
pipeline.addLast(executor, "decoder", new HttpResponseDecoder());
pipeline.addLast(executor, "aggregator", new HttpObjectAggregator(6291456));
pipeline.addLast(executor, "deserializer", new GatewayOutboundDeserializer());
pipeline.addLast(executor, "responseHanlder", new RouteResponseHandler());
pipeline.addLast(executor, "encoder", new HttpRequestEncoder());
pipeline.addLast(executor, "httpRequestBuilder", new GatewayEndpointRequestBuilder());
}
}
} |
|
I think this was fixed... Please re-open if this is not the case |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@normanmaurer @trustin
I have tested it with both JDK SSL and OpenSSL(tomcat-tcnative). Issue is present in both cases:
JDK 8, netty version 4.1.6.Final, running on MAC OS X El Capitan
(Unfortunately, the log message is too long, keeping it for clarity)
The text was updated successfully, but these errors were encountered: