feedback-to-code/mozzarella huggingface dataset:
Repository: netty/netty
Issue: New twitter hpack release

[0.9.1](https://github.com/twitter/hpack/releases/tag/v0.9.1) was released. We should pull this in for the http2 codec and examples. 


Issue comments:
@nmittler fyi

@Scottmitch this is addressed by #3016


Pull request review comments:

Patch that resolved the issue:
diff --git a/codec-http2/pom.xml b/codec-http2/pom.xml
index 5f79e09c96a..b3710b63f18 100644
--- a/codec-http2/pom.xml
+++ b/codec-http2/pom.xml
@@ -43,7 +43,6 @@
     <dependency>
       <groupId>com.twitter</groupId>
       <artifactId>hpack</artifactId>
-      <version>0.9.0</version>
     </dependency>
     <dependency>
       <groupId>org.mockito</groupId>
diff --git a/pom.xml b/pom.xml
index 9c8a2094f0d..cd2d767695a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -462,6 +462,11 @@
       </dependency>
 
       <!-- SPDY and HTTP/2 - completely optional -->
+      <dependency>
+        <groupId>com.twitter</groupId>
+        <artifactId>hpack</artifactId>
+        <version>0.9.1</version>
+      </dependency>
       <dependency>
         <groupId>org.eclipse.jetty.npn</groupId>
         <artifactId>npn-api</artifactId>


Test patch:
Repository: netty/netty
Issue: SslHandler wrap unconditionally copying to direct buffer
Labels: improvement

In light of a recent bug fix (https://github.com/netty/netty/pull/3058) it became evident that the SslHander wrap method was (and is still) unconditionally requiring a direct ByteBuffer for the input buffer to the SSLEngine.wrap() operation [here](https://github.com/netty/netty/blob/4.0/handler/src/main/java/io/netty/handler/ssl/SslHandler.java#L584).  Is it necessary (or even beneficial) to always do the the extra allocation and copy?  Should this conversion be conditional based upon the [wantsDirectBuffer](https://github.com/netty/netty/blob/4.0/handler/src/main/java/io/netty/handler/ssl/SslHandler.java#L187) boolean member variable, or some other condition?


Issue comments:
@normanmaurer and @trustin - Thoughts?

PR https://github.com/netty/netty/pull/3073 demonstrates using the `wantsDirectBuffer` variable to prevent requiring a direct byte buffer on every wrap.  This could be a big savings if non-direct byte buffers are used and direct byte buffers are not required (i.e. JDK ssl provider?).

@Scottmitch sounds legit to me... let us wait what @trustin things about it

@normanmaurer - Ok sounds good.

Cherry-picked changes into 4.0, 4.1 and master

@normanmaurer Thanks!


Pull request review comments:
This sounds legit... @trustin agree ? 


Patch that resolved the issue:
diff --git a/handler/src/main/java/io/netty/handler/ssl/SslHandler.java b/handler/src/main/java/io/netty/handler/ssl/SslHandler.java
index 9ea071d5292..3b683ff1e0c 100644
--- a/handler/src/main/java/io/netty/handler/ssl/SslHandler.java
+++ b/handler/src/main/java/io/netty/handler/ssl/SslHandler.java
@@ -182,7 +182,7 @@ public class SslHandler extends ByteToMessageDecoder implements ChannelOutboundH
     // BEGIN Platform-dependent flags
 
     /**
-     * {@code trus} if and only if {@link SSLEngine} expects a direct buffer.
+     * {@code true} if and only if {@link SSLEngine} expects a direct buffer.
      */
     private final boolean wantsDirectBuffer;
     /**
@@ -581,7 +581,7 @@ private SSLEngineResult wrap(ByteBufAllocator alloc, SSLEngine engine, ByteBuf i
         ByteBuf newDirectIn = null;
         try {
             final ByteBuffer in0;
-            if (in.isDirect()) {
+            if (in.isDirect() || !wantsDirectBuffer) {
                 in0 = in.nioBuffer();
             } else {
                 int readableBytes = in.readableBytes();


Test patch:
Repository: netty/netty
Issue: HTTP/2 draft 15
Labels: feature

Draft 15 is out http://tools.ietf.org/html/draft-ietf-httpbis-http2-15.  The impacts need to be investigated and the http/2 codec needs to be updated.


Issue comments:
@nmittler - FYI

@nmittler - I'm going to take a first pass at this...there are no framing changes.

See PR https://github.com/netty/netty/pull/3167

Cherry-picked updates.


Pull request review comments:

Patch that resolved the issue:
diff --git a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2SecurityUtil.java b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2SecurityUtil.java
index d5e68626aa9..792ebddf38c 100644
--- a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2SecurityUtil.java
+++ b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2SecurityUtil.java
@@ -49,9 +49,6 @@ public final class Http2SecurityUtil {
 
     private static final List<String> CIPHERS_JAVA_NO_MOZILLA_INCREASED_SECURITY = Collections.unmodifiableList(Arrays
             .asList(
-            /* Java 6,7,8 */
-            "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA", /* openssl = ECDHE-ECDSA-RC4-SHA */
-            "TLS_ECDH_ECDSA_WITH_RC4_128_SHA", /* openssl = ECDH-ECDSA-RC4-SHA */
             /* Java 8 */
             "TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384", /* openssl = ECDH-ECDSA-AES256-GCM-SHA384 */
             "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384", /* openssl = ECDH-RSA-AES256-GCM-SHA384 */
@@ -64,9 +61,7 @@ public final class Http2SecurityUtil {
     private static final List<String> CIPHERS_JAVA_DISABLED_DEFAULT = Collections.unmodifiableList(Arrays.asList(
             /* Java 8 */
             "TLS_DH_anon_WITH_AES_256_GCM_SHA384", /* openssl = ADH-AES256-GCM-SHA384 */
-            "TLS_DH_anon_WITH_AES_128_GCM_SHA256", /* openssl = ADH-AES128-GCM-SHA256 */
-            /* Java 6,7,8 */
-            "TLS_ECDH_anon_WITH_RC4_128_SHA" /* openssl = AECDH-RC4-SHA */));
+            "TLS_DH_anon_WITH_AES_128_GCM_SHA256" /* openssl = ADH-AES128-GCM-SHA256 */));
 
     static {
         List<String> ciphers = new ArrayList<String>(CIPHERS_JAVA_MOZILLA_INCREASED_SECURITY.size()


Test patch:
Repository: netty/netty
Issue: HTTP/2 HPACK 10
Labels: feature

[HPACK 10](https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-10) has been released.  We should update our [twitter hpack](https://github.com/twitter/hpack) dependencies.


Issue comments:
Addressed as part of https://github.com/netty/netty/pull/3217


Pull request review comments:

Patch that resolved the issue:
diff --git a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2CodecUtil.java b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2CodecUtil.java
index 3b0be13d598..b38aee2d6dd 100644
--- a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2CodecUtil.java
+++ b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2CodecUtil.java
@@ -34,8 +34,9 @@ public final class Http2CodecUtil {
     public static final int CONNECTION_STREAM_ID = 0;
     public static final int HTTP_UPGRADE_STREAM_ID = 1;
     public static final String HTTP_UPGRADE_SETTINGS_HEADER = "HTTP2-Settings";
-    public static final String HTTP_UPGRADE_PROTOCOL_NAME = "h2c-16";
-    public static final String TLS_UPGRADE_PROTOCOL_NAME = "h2-16";
+    // Draft 14 is the latest "implementation draft" as defined by https://http2.github.io/
+    public static final String HTTP_UPGRADE_PROTOCOL_NAME = "h2c-14";
+    public static final String TLS_UPGRADE_PROTOCOL_NAME = "h2-14";
 
     public static final int PING_FRAME_PAYLOAD_LENGTH = 8;
     public static final short MAX_UNSIGNED_BYTE = 0xFF;


Test patch:
Repository: netty/netty
Issue: Update Javassist from 3.18.0-GA to 3.19.0-GA

Javassist 3.19.0-GA released:
https://github.com/jboss-javassist/javassist/releases


Issue comments:
@ngocdaothanh we love PR's ;)


Pull request review comments:

Patch that resolved the issue:
diff --git a/pom.xml b/pom.xml
index 822c5463819..59122ad6349 100644
--- a/pom.xml
+++ b/pom.xml
@@ -31,7 +31,7 @@
   <name>Netty</name>
   <url>http://netty.io/</url>
   <description>
-    Netty is an asynchronous event-driven network application framework for 
+    Netty is an asynchronous event-driven network application framework for
     rapid development of maintainable high performance protocol servers and
     clients.
   </description>
@@ -512,7 +512,7 @@
       <dependency>
         <groupId>org.javassist</groupId>
         <artifactId>javassist</artifactId>
-        <version>3.18.0-GA</version>
+        <version>3.19.0-GA</version>
         <scope>compile</scope>
         <optional>true</optional>
       </dependency>
@@ -636,14 +636,14 @@
         </exclusions>
         <optional>true</optional>
       </dependency>
-      
+
       <!-- Metrics providers -->
       <dependency>
         <groupId>com.yammer.metrics</groupId>
         <artifactId>metrics-core</artifactId>
         <version>2.2.0</version>
       </dependency>
-      
+
       <!-- Common test dependencies -->
       <dependency>
         <groupId>junit</groupId>
@@ -979,7 +979,7 @@
             </configuration>
           </execution>
         </executions>
-      </plugin>             
+      </plugin>
       <plugin>
         <artifactId>maven-source-plugin</artifactId>
         <version>2.2.1</version>
@@ -1238,7 +1238,7 @@
           <groupId>org.codehaus.mojo</groupId>
           <artifactId>build-helper-maven-plugin</artifactId>
           <version>1.8</version>
-        </plugin>               
+        </plugin>
         <plugin>
           <groupId>org.fusesource.hawtjni</groupId>
           <artifactId>maven-hawtjni-plugin</artifactId>


Test patch:
Repository: netty/netty
Issue: EpollDatagramChannel never calls fireChannelActive() after connect()
Labels: defect

NioDatagramChannel extends AbstractNioChannel and AbstractNioUnsafe call fulfillConnectPromise(), which calls fireChannelActive()

AbstractEpollUnsafe and EpollDatagramChannel have no equivalent call, so channelActive() is never called on the pipeline.


Issue comments:
I think it may also not be unregistering closed datagram sockets, but I haven't traced that.

Sounds like a bug... will investigate

Fixed... sorry for the delay.


Pull request review comments:

Patch that resolved the issue:
diff --git a/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java b/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java
index f3809865c08..53465608bf0 100644
--- a/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java
+++ b/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java
@@ -483,6 +483,7 @@ public void connect(SocketAddress remote, SocketAddress local, ChannelPromise ch
             boolean success = false;
             try {
                 try {
+                    boolean wasActive = isActive();
                     InetSocketAddress remoteAddress = (InetSocketAddress) remote;
                     if (local != null) {
                         InetSocketAddress localAddress = (InetSocketAddress) local;
@@ -493,6 +494,12 @@ public void connect(SocketAddress remote, SocketAddress local, ChannelPromise ch
                     EpollDatagramChannel.this.remote = remoteAddress;
                     EpollDatagramChannel.this.local = Native.localAddress(fd().intValue());
                     success = true;
+
+                    // Regardless if the connection attempt was cancelled, channelActive() event should be triggered,
+                    // because what happened is what happened.
+                    if (!wasActive && isActive()) {
+                        pipeline().fireChannelActive();
+                    }
                 } finally {
                     if (!success) {
                         doClose();


Test patch:
Repository: netty/netty
Issue: NormalMemoryRegionCache's arraysize is over booked
Labels: defect

When create NormalMemoryRegionCache for PoolThreadCache. The array size is decided by:
        int max = Math.min(area.chunkSize, maxCachedBufferCapacity);
        int arraySize = Math.max(1, max / area.pageSize);

So most likely it is decided by maxCachedBufferCapacity/area.pageSize, with maxCachedBufferCapacity=2M the array size will be 2^8 = 256.

when we try to get normal cache the index is pre-processed by log2():
PoolThreadCache.cacheForNormal():
        int idx = log2(normCapacity >> numShiftsNormalHeap);
        return cache(normalHeapCaches, idx);

A 2M cache entry will get from the 8th cache bin(start from 0).

The space for NormalMemoryRegionCache is over booked, though it will not impact correctness(just a little performance..).


Issue comments:
@garretwu thanks for reporting... I will check and fix it

@garretwu I'm right you say it should get the 7th cache bin(start from0) . right ?

you are right, @normanmaurer. That is what I mean.

Thanks for clarify!

> Am 12.11.2014 um 03:52 schrieb garretwu notifications@github.com:
> 
> you are right, @normanmaurer. That is what I mean.
> 
> —
> Reply to this email directly or view it on GitHub.

Totally forgot about this. Will look into it or would you want to submit a pr @garretwu ? We love contributions :)

@garretwu what you think about provide a PR for this ? I'm still not 100 % sure I understand the issue correctly, so maybe it would be the easiest to just have you fix it ;)

sure, I could create a PR:)

This would be awesome!

> Am 11.04.2015 um 00:02 schrieb garretwu notifications@github.com:
> 
> sure, I could create a PR:)
> 
> —
> Reply to this email directly or view it on GitHub.

Hi @normanmaurer. 
PR: https://github.com/netty/netty/pull/3624 is created for such issue.

mvn test pass.

end to end test:
Dumped heap to check.
with Dio.netty.allocator.maxCachedBufferCapacity: 32768 (cache max 32K),
NormalMemoryRegionCache size is 3(8k, 16k, 32k), rather than previous 4.

Fixed by #3624


Pull request review comments:

Patch that resolved the issue:
diff --git a/buffer/src/main/java/io/netty/buffer/PoolThreadCache.java b/buffer/src/main/java/io/netty/buffer/PoolThreadCache.java
index 755f1573ed7..fbcfaafffb1 100644
--- a/buffer/src/main/java/io/netty/buffer/PoolThreadCache.java
+++ b/buffer/src/main/java/io/netty/buffer/PoolThreadCache.java
@@ -129,7 +129,7 @@ private static <T> NormalMemoryRegionCache<T>[] createNormalCaches(
             int cacheSize, int maxCachedBufferCapacity, PoolArena<T> area) {
         if (cacheSize > 0) {
             int max = Math.min(area.chunkSize, maxCachedBufferCapacity);
-            int arraySize = Math.max(1, max / area.pageSize);
+            int arraySize = Math.max(1, log2(max / area.pageSize) + 1);
 
             @SuppressWarnings("unchecked")
             NormalMemoryRegionCache<T>[] cache = new NormalMemoryRegionCache[arraySize];


Test patch:
Repository: netty/netty
Issue: [typo]it seems to be a typo 'reyclable' in RecyclableArrayList

in line 28,it writes '\* A simple list which is reyclable.' ,i guess here should be recyclable. :p


Issue comments:
We love PR's ;)

> Am 06.05.2015 um 03:40 schrieb Thomas notifications@github.com:
> 
> in line 28,it writes '\* A simple list which is reyclable.' ,i guess here should be recyclable. :p
> 
> —
> Reply to this email directly or view it on GitHub.

thanks @normanmaurer  i just pulled it.:)


Pull request review comments:

Patch that resolved the issue:
diff --git a/common/src/main/java/io/netty/util/internal/RecyclableArrayList.java b/common/src/main/java/io/netty/util/internal/RecyclableArrayList.java
index 9a4214f9a6a..38847bd2790 100644
--- a/common/src/main/java/io/netty/util/internal/RecyclableArrayList.java
+++ b/common/src/main/java/io/netty/util/internal/RecyclableArrayList.java
@@ -25,7 +25,7 @@
 import java.util.RandomAccess;
 
 /**
- * A simple list which is reyclable. This implementation does not allow {@code null} elements to be added.
+ * A simple list which is recyclable. This implementation does not allow {@code null} elements to be added.
  */
 public final class RecyclableArrayList extends ArrayList<Object> {
 


Test patch:
Repository: netty/netty
Issue: OpenSSL SSLSession returns incorrect peer principal
Labels: defect

According to the docs for `javax.net.ssl.SSLSession` (http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLSession.html#getPeerPrincipal()), `getPeerPrincipal` should be returning the identity of the peer.

The OpenSSL based implementation for Netty, however, is returning the identity of the issuer:
https://github.com/netty/netty/blob/netty-4.0.28.Final/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java#L1406
`getPeerPrincipal()` calls `principal(certs)`, which casts to `X509Certificate` and calls `getIssuerX500Principal()` when it should be calling `getSubject500Principal()`.

The JDK based implementation returns the correct principal.


Issue comments:
@edwinchoi thanks for the report... Will fix it

@edwinchoi can you verify the fix:

https://github.com/netty/netty/pull/3889

Thanks!

@normanmaurer works as expected now, thanks!

Fixed


Pull request review comments:

Patch that resolved the issue:
diff --git a/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java b/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java
index 53ef4334465..756c11fb163 100644
--- a/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java
+++ b/handler/src/main/java/io/netty/handler/ssl/OpenSslEngine.java
@@ -1446,7 +1446,7 @@ public Principal getPeerPrincipal() throws SSLPeerUnverifiedException {
             if (peer == null || peer.length == 0) {
                 return null;
             }
-            return principal(peer);
+            return ((java.security.cert.X509Certificate) peer[0]).getSubjectX500Principal();
         }
 
         @Override
@@ -1455,11 +1455,7 @@ public Principal getLocalPrincipal() {
             if (local == null || local.length == 0) {
                 return null;
             }
-            return principal(local);
-        }
-
-        private Principal principal(Certificate[] certs) {
-            return ((java.security.cert.X509Certificate) certs[0]).getIssuerX500Principal();
+            return ((java.security.cert.X509Certificate) local[0]).getIssuerX500Principal();
         }
 
         @Override


Test patch:
Repository: netty/netty
Issue: FixedChannelPool creates 1 more channel than maxConnections
Labels: defect

Netty version: 4.0.10.Beta5

Context:
1 more channel was created, when I tried to acquire channel via `FixedChannelPool.acquire`

Steps to reproduct:
1. Create a `FixedChannelPool` with `N`  `maxConnections`
2. Call `FixedChannelPool.acquire` from enough many thread
3. `N+1` channels is created.

Opinion:
It looks like

https://github.com/netty/netty/blob/master/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java#L267

``` java
while (acquiredChannelCount <= maxConnections) {
```

should be 

``` java
while (acquiredChannelCount < maxConnections) {
```


Issue comments:
@fratboy - Thanks for reporting!

@normanmaurer - Seems legit. WDYT?

@Scottmitch yep, will fix

Fixed

:+1: 


Pull request review comments:

Patch that resolved the issue:
diff --git a/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java b/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java
index 1066358dd60..ddafebb8d3a 100644
--- a/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java
+++ b/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java
@@ -264,7 +264,7 @@ private void decrementAndRunTaskQueue() {
     }
 
     private void runTaskQueue() {
-        while (acquiredChannelCount <= maxConnections) {
+        while (acquiredChannelCount < maxConnections) {
             AcquireTask task = pendingAcquireQueue.poll();
             if (task == null) {
                 break;


Test patch:
Repository: netty/netty
Issue: Number of PoolArena's should be 2 * cores
Labels: improvement

We use 2 \* cores as the default number of EventLoop's for NIO and EPOLL, so we should do the same for the numbers of PoolArena's. This will reduce conditions.

jemalloc itself even use 4 \* cpus:
http://www.canonware.com/download/jemalloc/jemalloc-latest/doc/jemalloc.html

Related to:

https://groups.google.com/d/msg/netty/J78updTXPTU/T6-i_O6Hxu4J


Issue comments:
@purplefox FYI

Fixed


Pull request review comments:

Patch that resolved the issue:
diff --git a/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java b/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java
index 1ea167883ff..148e6ec0d22 100644
--- a/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java
+++ b/buffer/src/main/java/io/netty/buffer/PooledByteBufAllocator.java
@@ -69,18 +69,24 @@ public class PooledByteBufAllocator extends AbstractByteBufAllocator {
         // Determine reasonable default for nHeapArena and nDirectArena.
         // Assuming each arena has 3 chunks, the pool should not consume more than 50% of max memory.
         final Runtime runtime = Runtime.getRuntime();
+
+        // Use 2 * cores by default to reduce condition as we use 2 * cores for the number of EventLoops
+        // in NIO and EPOLL as well. If we choose a smaller number we will run into hotspots as allocation and
+        // deallocation needs to be synchronized on the PoolArena.
+        // See https://github.com/netty/netty/issues/3888
+        final int defaultMinNumArena = runtime.availableProcessors() * 2;
         final int defaultChunkSize = DEFAULT_PAGE_SIZE << DEFAULT_MAX_ORDER;
         DEFAULT_NUM_HEAP_ARENA = Math.max(0,
                 SystemPropertyUtil.getInt(
                         "io.netty.allocator.numHeapArenas",
                         (int) Math.min(
-                                runtime.availableProcessors(),
-                                Runtime.getRuntime().maxMemory() / defaultChunkSize / 2 / 3)));
+                                defaultMinNumArena,
+                                runtime.maxMemory() / defaultChunkSize / 2 / 3)));
         DEFAULT_NUM_DIRECT_ARENA = Math.max(0,
                 SystemPropertyUtil.getInt(
                         "io.netty.allocator.numDirectArenas",
                         (int) Math.min(
-                                runtime.availableProcessors(),
+                                defaultMinNumArena,
                                 PlatformDependent.maxDirectMemory() / defaultChunkSize / 2 / 3)));
 
         // cache sizes
@@ -202,7 +208,7 @@ public PooledByteBufAllocator(boolean preferDirect, int nHeapArena, int nDirectA
                                   int tinyCacheSize, int smallCacheSize, int normalCacheSize,
                                   long cacheThreadAliveCheckInterval) {
         this(preferDirect, nHeapArena, nDirectArena, pageSize, maxOrder,
-                tinyCacheSize, smallCacheSize, normalCacheSize);
+             tinyCacheSize, smallCacheSize, normalCacheSize);
     }
 
     @SuppressWarnings("unchecked")


Test patch:
Repository: netty/netty
Issue: `OpenSslServerContext.setTicketKeys` does not works in 3.x

There are invalid check arguments in 'OpenSslServerContext.setTicketKeys'.

```
        public void setTicketKeys(byte[] keys) {
        if (keys != null) {
            throw new NullPointerException("keys");
        }

```


Issue comments:
@0mok - Should this be closed?

Yes.


Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/jboss/netty/handler/ssl/OpenSslServerContext.java b/src/main/java/org/jboss/netty/handler/ssl/OpenSslServerContext.java
index 15a15ac9656..f6e7b3ef7ab 100644
--- a/src/main/java/org/jboss/netty/handler/ssl/OpenSslServerContext.java
+++ b/src/main/java/org/jboss/netty/handler/ssl/OpenSslServerContext.java
@@ -331,7 +331,7 @@ public SSLEngine newEngine(String peerHost, int peerPort) {
      * Sets the SSL session ticket keys of this context.
      */
     public void setTicketKeys(byte[] keys) {
-        if (keys != null) {
+        if (keys == null) {
             throw new NullPointerException("keys");
         }
         SSLContext.setSessionTicketKeys(ctx, keys);


Test patch: