I am using netty-tcnative with SslProvider.OPENSSL provider. I see a warning msg in GC log analyzer about finalizers which I am suspecting is mostly because of it.
[Warning] At one point 25872 objects were queued for finalization.
Using finalizers is not recommended as it can slow garbage collection and cause wasted space in the heap.
Consider reviewing your application for occurrences of the finalize() method.
I see Netty provides another option SslProvider.OPENSSL_REFCNT which does not have finalizers and instead implements ReferenceCounted.
- I am wondering if it is a drop-in replacement of
SslProvider.OPENSSL or if it needs more changes.
- Is it production ready? I see it is marked as
@UnstableApi. Any known side effects or issues?
- Does it perform better than
SslProvider.OPENSSL for low latency high throughput system?
SslProvider provider = SslProvider.isAlpnSupported(SslProvider.OPENSSL) ? SslProvider.OPENSSL : SslProvider.JDK;
logger.info("SSL provider: {}", provider);
sslCtx = SslContextBuilder.forServer(keyManagerFactory)
.sslProvider(provider)
.ciphers(cypherList)
.applicationProtocolConfig(new ApplicationProtocolConfig(
Protocol.ALPN,
SelectorFailureBehavior.NO_ADVERTISE,
SelectedListenerFailureBehavior.ACCEPT,
ApplicationProtocolNames.HTTP_1_1
))
.sessionCacheSize(SSL_SESSION_CACHE_SIZE) // 1800 -> 30 mins
.sessionTimeout(SSL_SESSION_CACHE_TIMEOUT_SECOND) // 1024 * 100 -> 1000_00 sessions
.build();
// DefaultServerInitializer
public void initChannel(SocketChannel ch) {
...
if (sslContext != null) {
pipeline.addLast(sslContext.newHandler(ch.alloc()));
}
...
}
I am using
netty-tcnativewithSslProvider.OPENSSLprovider. I see a warning msg in GC log analyzer aboutfinalizerswhich I am suspecting is mostly because of it.I see Netty provides another option
SslProvider.OPENSSL_REFCNTwhich does not have finalizers and instead implements ReferenceCounted.SslProvider.OPENSSLor if it needs more changes.@UnstableApi. Any known side effects or issues?SslProvider.OPENSSLfor low latency high throughput system?