feedback-to-code/mozzarella huggingface dataset:
Repository: netty/netty
Issue: git conflict markers in public javadoc
Labels: cleanup

The following file contains git conflict markers: https://github.com/netty/netty/blob/4.0/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java#L107

These conflict markers are visible in the public javadoc for the hashcode and hexdump methods:

https://netty.io/4.0/api/io/netty/buffer/ByteBufUtil.html


Issue comments:
ups... let me fix it.

thanks for reporting @ferrybig !

Fixed by https://github.com/netty/netty/pull/5725


Pull request review comments:

Patch that resolved the issue:
diff --git a/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java b/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java
index f405d496cf1..1ff9efb5faa 100644
--- a/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java
+++ b/buffer/src/main/java/io/netty/buffer/ByteBufUtil.java
@@ -103,8 +103,6 @@ public static String hexDump(ByteBuf buffer, int fromIndex, int length) {
     }
 
     /**
-<<<<<<< HEAD
-=======
      * Returns a <a href="http://en.wikipedia.org/wiki/Hex_dump">hex dump</a>
      * of the specified byte array.
      */
@@ -121,7 +119,6 @@ public static String hexDump(byte[] array, int fromIndex, int length) {
     }
 
     /**
->>>>>>> e5386b0... Move Hex dump related util from ByteBufUtil to inner class
      * Calculates the hash code of the specified buffer.  This method is
      * useful when implementing a new buffer type.
      */


Test patch:
Repository: netty/netty
Issue: DefaultEventLoopGroup doesn't expose ctor variant that accepts custom Executor

The `DefaultEventLoopGroup` class extends `MultithreadEventExecutorGroup` but doesn't expose the ctor variants that accept a custom Executor like `NioEventLoopGroup` and `EpollEventLoopGroup` do.

Is that on purpose or just an oversight?


Issue comments:
@rkapsi oversight... let me fix it.

Fixed by https://github.com/netty/netty/pull/5782


Pull request review comments:

Patch that resolved the issue:
diff --git a/transport/src/main/java/io/netty/channel/DefaultEventLoopGroup.java b/transport/src/main/java/io/netty/channel/DefaultEventLoopGroup.java
index 6e8ba13452f..ee5eeea6418 100644
--- a/transport/src/main/java/io/netty/channel/DefaultEventLoopGroup.java
+++ b/transport/src/main/java/io/netty/channel/DefaultEventLoopGroup.java
@@ -36,7 +36,7 @@ public DefaultEventLoopGroup() {
      * @param nThreads          the number of threads to use
      */
     public DefaultEventLoopGroup(int nThreads) {
-        this(nThreads, null);
+        this(nThreads, (ThreadFactory) null);
     }
 
     /**
@@ -49,6 +49,16 @@ public DefaultEventLoopGroup(int nThreads, ThreadFactory threadFactory) {
         super(nThreads, threadFactory);
     }
 
+    /**
+     * Create a new instance
+     *
+     * @param nThreads          the number of threads to use
+     * @param executor          the Executor to use, or {@code null} if the default should be used.
+     */
+    public DefaultEventLoopGroup(int nThreads, Executor executor) {
+        super(nThreads, executor);
+    }
+
     @Override
     protected EventLoop newChild(Executor executor, Object... args) throws Exception {
         return new DefaultEventLoop(this, executor);


Test patch:
Repository: netty/netty
Issue: Allow clients to override userDefinedWritabilityIndex from AbstractTrafficShapingHandler
Labels: improvement

Hello, 

AbstractTrafficShapingHandler has a package-private method called "userDefinedWritabilityIndex()". If I create two sub-classes of ChannelTrafficShapingHandler (one for throttling on bandwidth and the other for throttling on message size), I cannot make them independent from each other in terms of writability, because they will all have the same index as ChannelTrafficShapingHandler, which cannot be overridden. 

Can we change the access of userDefinedWritabilityIndex() to _protected_ such that it can be overridden by clients? 

Thanks

Michael


Issue comments:
/cc @fredericBregier 

Let me take care

@normanmaurer Sorry to be late again (very busy those last 9 months). I look at your commit, fine for me.

Fixed by https://github.com/netty/netty/pull/5791

Thanks guys! I could've sent you a poll request but wasn't sure if this is the right design. 


Pull request review comments:

Patch that resolved the issue:
diff --git a/handler/src/main/java/io/netty/handler/traffic/AbstractTrafficShapingHandler.java b/handler/src/main/java/io/netty/handler/traffic/AbstractTrafficShapingHandler.java
index 9cff40f0cef..fb4cdce3e22 100644
--- a/handler/src/main/java/io/netty/handler/traffic/AbstractTrafficShapingHandler.java
+++ b/handler/src/main/java/io/netty/handler/traffic/AbstractTrafficShapingHandler.java
@@ -145,7 +145,7 @@ void setTrafficCounter(TrafficCounter newTrafficCounter) {
      *              for GlobalChannel TSH it is defined as
      *              {@value #GLOBALCHANNEL_DEFAULT_USER_DEFINED_WRITABILITY_INDEX}.
      */
-    int userDefinedWritabilityIndex() {
+    protected int userDefinedWritabilityIndex() {
         if (this instanceof GlobalChannelTrafficShapingHandler) {
             return GLOBALCHANNEL_DEFAULT_USER_DEFINED_WRITABILITY_INDEX;
         } else if (this instanceof GlobalTrafficShapingHandler) {
diff --git a/handler/src/main/java/io/netty/handler/traffic/GlobalChannelTrafficShapingHandler.java b/handler/src/main/java/io/netty/handler/traffic/GlobalChannelTrafficShapingHandler.java
index 91a68f0a0e0..8b257eb7f05 100644
--- a/handler/src/main/java/io/netty/handler/traffic/GlobalChannelTrafficShapingHandler.java
+++ b/handler/src/main/java/io/netty/handler/traffic/GlobalChannelTrafficShapingHandler.java
@@ -156,7 +156,7 @@ void createGlobalTrafficCounter(ScheduledExecutorService executor) {
     }
 
     @Override
-    int userDefinedWritabilityIndex() {
+    protected int userDefinedWritabilityIndex() {
         return AbstractTrafficShapingHandler.GLOBALCHANNEL_DEFAULT_USER_DEFINED_WRITABILITY_INDEX;
     }
 


Test patch:
Repository: netty/netty
Issue: Http2EventAdapter's onUnknownFrame() is missing throws Http2Exception
Labels: defect

`Http2EventAdapter` implements the `Http2FrameListener` interface but implements the `#onUnknownFrame(...)` method without the interface's `throws Http2Exception`.

... causing compiler errors down the road if you're trying to implement a delegate or something like that.


Issue comments:
Let me fix it

Fixes by https://github.com/netty/netty/pull/5876


Pull request review comments:

Patch that resolved the issue:
diff --git a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2EventAdapter.java b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2EventAdapter.java
index 3f5665a40eb..b51e083f150 100644
--- a/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2EventAdapter.java
+++ b/codec-http2/src/main/java/io/netty/handler/codec/http2/Http2EventAdapter.java
@@ -82,7 +82,7 @@ public void onWindowUpdateRead(ChannelHandlerContext ctx, int streamId, int wind
 
     @Override
     public void onUnknownFrame(ChannelHandlerContext ctx, byte frameType, int streamId, Http2Flags flags,
-            ByteBuf payload) {
+            ByteBuf payload) throws Http2Exception {
     }
 
     @Override


Test patch:
Repository: netty/netty
Issue: HttpUtil.getContentLength(HttpMessage, long) throws unexpected NumberFormatException
Labels: defect

The Javadocs of `HttpUtil.getContentLength(HttpMessage, long)` and its `int` overload state that the provided default value is returned if the Content-Length value is not a number. `NumberFormatException` is thrown instead [1] causing the method to behave like `HttpUtil.getContentLength(HttpMessage)` where the exception is explicitly documented for this case.

[1] https://github.com/netty/netty/blob/149916d052180dd2b0e0e98598f349454ea200ba/codec-http/src/main/java/io/netty/handler/codec/http/HttpUtil.java#L187


Issue comments:
@ewie sounds like a bug... let me fix it.

@ewie should be fixed by https://github.com/netty/netty/pull/5877

Fixed by https://github.com/netty/netty/pull/5877


Pull request review comments:

Patch that resolved the issue:
diff --git a/codec-http/src/main/java/io/netty/handler/codec/http/HttpUtil.java b/codec-http/src/main/java/io/netty/handler/codec/http/HttpUtil.java
index 0d9433c698b..4d165088e67 100644
--- a/codec-http/src/main/java/io/netty/handler/codec/http/HttpUtil.java
+++ b/codec-http/src/main/java/io/netty/handler/codec/http/HttpUtil.java
@@ -184,7 +184,11 @@ public static long getContentLength(HttpMessage message) {
     public static long getContentLength(HttpMessage message, long defaultValue) {
         String value = message.headers().get(HttpHeaderNames.CONTENT_LENGTH);
         if (value != null) {
-            return Long.parseLong(value);
+            try {
+                return Long.parseLong(value);
+            } catch (NumberFormatException ignore) {
+                return defaultValue;
+            }
         }
 
         // We know the content length if it's a Web Socket message even if


Test patch:
diff --git a/codec-http/src/test/java/io/netty/handler/codec/http/HttpUtilTest.java b/codec-http/src/test/java/io/netty/handler/codec/http/HttpUtilTest.java
index 1e9615ce8f5..93478d645d0 100644
--- a/codec-http/src/test/java/io/netty/handler/codec/http/HttpUtilTest.java
+++ b/codec-http/src/test/java/io/netty/handler/codec/http/HttpUtilTest.java
@@ -100,4 +100,13 @@ public void testGetMimeType() {
         message.headers().set(HttpHeaderNames.CONTENT_TYPE, "text/html; charset=utf-8");
         assertEquals("text/html", HttpUtil.getMimeType(message));
     }
+
+    @Test
+    public void testGetContentLengthDefaultValue() {
+        HttpMessage message = new DefaultHttpResponse(HttpVersion.HTTP_1_1, HttpResponseStatus.OK);
+        assertNull(message.headers().get(HttpHeaderNames.CONTENT_LENGTH));
+        message.headers().set(HttpHeaderNames.CONTENT_LENGTH, "bar");
+        assertEquals("bar", message.headers().get(HttpHeaderNames.CONTENT_LENGTH));
+        assertEquals(1L, HttpUtil.getContentLength(message, 1L));
+    }
 }
Repository: netty/netty
Issue: Make FixedChannelPool non final

We use **FixedChannelPool**  in our project. But we have some problems adopting it to our needs. For example, we want to override methods **_pollChannel_** and **_offerChannel_** for monitoring purposes. We want to monitor count of channel objects in the pool. But it is difficult because **FixedChannelPool** is final. Could you consider removing final keyword from it, please?

Issue comments:
Sounds ok to me... @Scottmitch ?

sgtm
@derbylock could you provide a PR ?
Fixed by https://github.com/netty/netty/pull/6059

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 cefedee89fb..8c69dc7b0da 100644
--- a/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java
+++ b/transport/src/main/java/io/netty/channel/pool/FixedChannelPool.java
@@ -34,7 +34,7 @@
  * {@link ChannelPool} implementation that takes another {@link ChannelPool} implementation and enforce a maximum
  * number of concurrent connections.
  */
-public final class FixedChannelPool extends SimpleChannelPool {
+public class FixedChannelPool extends SimpleChannelPool {
     private static final IllegalStateException FULL_EXCEPTION = ThrowableUtil.unknownStackTrace(
             new IllegalStateException("Too many outstanding acquire operations"),
             FixedChannelPool.class, "acquire0(...)");


Test patch:
Repository: netty/netty
Issue: EpollServerDomainSocketChannel.isActive() return false after bind operation succeed
Labels: defect

Netty version: 4.1.0.Final

Context: I found bug on EpollServerDomainSocketChannel class. Its isActive() method always return false. It is required to set isActive = true in doBind() operation like EpollServerSocketChannel.

Steps to reproduce:
1. Use EpollServerDomainSocketChannel class to server bootstrap's channel class
2. Bind any unix domain socket.
3. Server Channel's channelActive() is not called due to EpollServerDomainSocketChannel.isActive() return false.

$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

Operating system: Cent OS 7.2 64-bit

$ uname -a
Linux  3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Issue comments:
Will check later today

> Am 25.11.2016 um 04:45 schrieb byeongguk.gim <notifications@github.com>:
> 
> Netty version: 4.1.0.Final
> 
> Context: I found bug on EpollServerDomainSocketChannel class. Its isActive() method always return false. It is required to set isActive = true in doBind() operation. (same as EpollServerSocketChannel)
> 
> Steps to reproduce:
> 
> Use EpollServerDomainSocketChannel class to server bootstrap's channel class
> Bind any unix domain socket.
> Server Channel's channelActive() is not called due to EpollServerDomainSocketChannel.isActive() return false.
> $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> 
> Operating system: Cent OS 7.2 64-bit
> 
> $ uname -a
> Linux 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 

@byoengguk thanks for reporting... you are right. Let me fix this
Fixed by https://github.com/netty/netty/pull/6078

Pull request review comments:

Patch that resolved the issue:
diff --git a/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollServerDomainSocketChannel.java b/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollServerDomainSocketChannel.java
index 958d85a4240..c533d24ea1c 100644
--- a/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollServerDomainSocketChannel.java
+++ b/transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollServerDomainSocketChannel.java
@@ -75,6 +75,7 @@ protected void doBind(SocketAddress localAddress) throws Exception {
         fd().bind(localAddress);
         fd().listen(config.getBacklog());
         local = (DomainSocketAddress) localAddress;
+        active = true;
     }
 
     @Override


Test patch:
Repository: netty/netty
Issue: PlatformDependent doesn't prefer JDK8 LongAdder 
Labels: improvement

I am running Netty on Java 8.

```
    /**
     * Creates a new fastest {@link LongCounter} implementaion for the current platform.
     */
    public static LongCounter newLongCounter() {
        if (HAS_UNSAFE) {
            return new LongAdderV8();
        } else {
            return new AtomicLongCounter();
        }
    }
```

On a normal modern Java8, where HAS_UNSAFE is true, this will always use the c&p LongAdderV8, otherwise the JDK Shipped AtomicLongCounter. Assuming that the JDK8 contained LongAdder is "better" (e.g. it might use intrinsics) I was wondering why there is no Java >=8 check which will directly use the JDK8 LongAdder (wrapped to comply to netty interface)

(also note the c&p typo "implementaion" in many of the javadocs)


Issue comments:
@CodingFabian I will fix this.

@CodingFabian seems like there is no way to fix this as we still need to support java6 :(

Huh? Cant you keep the current if else and just wrap with an if else that checks version and if >=8 delegates to the JDK  Version? You might need an indirection to avoid classloading in <8

@CodingFabian there are no specific intrinsics for `LongAdder`. However I agree that it is better to use JDK version as netty version differs from latest JDK version.

> You might need an indirection to avoid classloading in <8

Could you please show code example of what do you mean?

@CodingFabian something like this? https://github.com/netty/netty/pull/5794

Fixed by https://github.com/netty/netty/pull/6379

Pull request review comments:

Patch that resolved the issue:
diff --git a/pom.xml b/pom.xml
index 28334609c54..76062141540 100644
--- a/pom.xml
+++ b/pom.xml
@@ -596,9 +596,9 @@
             <configuration>
               <rules>
                 <requireJavaVersion>
-                  <!-- Enforce JDK 1.7+ for compilation. -->
+                  <!-- Enforce JDK 1.8+ for compilation. -->
                   <!-- This is needed because of java.util.zip.Deflater and NIO UDP multicast. -->
-                  <version>[1.7.0,)</version>
+                  <version>[1.8.0,)</version>
                 </requireJavaVersion>
                 <requireMavenVersion>
                   <version>[3.1.1,)</version>


Test patch:
Repository: netty/netty
Issue: Could not find artifact io.netty:netty-tcnative:jar:osx-x86_64:2.0.1.Final-SNAPSHOT

### Expected behavior
mvn -s ~/.m2/settings_default.xml package is ok.

### Actual behavior
Could not find artifact io.netty:netty-tcnative:jar:osx-x86_64:2.0.1.Final-SNAPSHOT

### Steps to reproduce
1.git clone https://github.com/netty/netty.git
2.mvn -s ~/.m2/settings_default.xml package


### Minimal yet complete reproducer code (or URL to code)

### Netty version
latest source code on 4.1 branch

### JVM version (e.g. `java -version`)
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

### OS version (e.g. `uname -a`)
Darwin tinyhuiwang 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64 i386 MacBookPro12,1 Darwin

### others
I found in pom.xml(netty-parent)，the tcnative.version is 2.0.1.Final-SNAPSHOT,but in http://repo1.maven.org/maven2/io/netty/netty-tcnative/ ,can not find this version ,only 2.0.0,and not SNAPSHOT.

Issue comments:
Fixed... we now also deploy the OS X snapshot version
Which remote repository will upload? Is it only sonatype-nexus?
https://oss.sonatype.org/content/repositories/snapshots/io/netty/netty-tcnative/2.0.1.Final-SNAPSHOT/

We will release a final version this week tho
At this time ,the final version is not release.
@qiaodaimadelaowang it is... Why you say otherwise ?

http://repo1.maven.org/maven2/io/netty/netty-tcnative/2.0.1.Final/
Sorry.
Final version in http://repo1.maven.org/maven2/io/netty/netty-tcnative/
and SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots/io/netty/netty-tcnative ?
Yes

> Am 28.04.2017 um 12:08 schrieb tinyhui.wang <notifications@github.com>:
> 
> Final version in http://repo1.maven.org/maven2/io/netty/netty-tcnative/
> and SNAPSHOT in https://oss.sonatype.org/content/repositories/snapshots/io/netty/netty-tcnative ?
> 
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


Pull request review comments:

Patch that resolved the issue:
diff --git a/pom.xml b/pom.xml
index a2ebfb0ce6d..86d54c3ce3f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -242,7 +242,7 @@
     <!-- Fedora-"like" systems. This is currently only used for the netty-tcnative dependency -->
     <os.detection.classifierWithLikes>fedora</os.detection.classifierWithLikes>
     <tcnative.artifactId>netty-tcnative</tcnative.artifactId>
-    <tcnative.version>2.0.1.Final-SNAPSHOT</tcnative.version>
+    <tcnative.version>2.0.1.Final</tcnative.version>
     <tcnative.classifier>${os.detected.classifier}</tcnative.classifier>
     <conscrypt.groupId>org.conscrypt</conscrypt.groupId>
     <conscrypt.artifactId>conscrypt-openjdk-uber</conscrypt.artifactId>


Test patch:
Repository: netty/netty
Issue: io.netty.internal.tcnative.* classes bundled with netty-all JAR
Labels: defect

I believe none of the `io.netty.internal.tcnative.*` classes is supposed to be bundled with the netty-all JAR but they are...

```bash
$ unzip netty-all-4.1.11.Final.jar | grep tcnative
   creating: io/netty/internal/tcnative/
  inflating: io/netty/internal/tcnative/SSL.class  
  inflating: io/netty/internal/tcnative/Buffer.class  
  inflating: io/netty/internal/tcnative/NativeStaticallyReferencedJniMethods.class  
  inflating: io/netty/internal/tcnative/SSLContext.class  
  inflating: io/netty/internal/tcnative/CertificateRequestedCallback.class  
  inflating: io/netty/internal/tcnative/SniHostNameMatcher.class  
  inflating: io/netty/internal/tcnative/Library.class  
  inflating: io/netty/internal/tcnative/SessionTicketKey.class  
  inflating: io/netty/internal/tcnative/CertificateRequestedCallback$KeyMaterial.class  
  inflating: io/netty/internal/tcnative/CertificateVerifier.class 
```
... causing classpath problems if one is trying to use the netty-all JAR along with a custom TCN build.

### Expected behavior

### Actual behavior

### Steps to reproduce

### Minimal yet complete reproducer code (or URL to code)

### Netty version

### JVM version (e.g. `java -version`)

### OS version (e.g. `uname -a`)


Issue comments:
@rkapsi will check
@rkapsi Please check https://github.com/netty/netty/pull/6793

Pull request review comments:

Patch that resolved the issue:
diff --git a/all/pom.xml b/all/pom.xml
index 47e763f50de..d7b0b124eb0 100644
--- a/all/pom.xml
+++ b/all/pom.xml
@@ -551,7 +551,7 @@
               <goal>unpack-dependencies</goal>
             </goals>
             <configuration>
-              <excludes>io/netty/example/**,META-INF/native/libnetty-tcnative*,META-INF/native/include/**,META-INF/native/**/*.a</excludes>
+              <excludes>io/netty/internal/tcnative/**,io/netty/example/**,META-INF/native/libnetty-tcnative*,META-INF/native/include/**,META-INF/native/**/*.a</excludes>
               <includes>io/netty/**,META-INF/native/**</includes>
               <includeScope>runtime</includeScope>
               <includeGroupIds>${project.groupId}</includeGroupIds>


Test patch:
Repository: netty/netty
Issue: 4.1.12.Final bom uses 4.1.12.Final-SNAPSHOT for the version of netty-transport-unix-common
Labels: defect

### Expected behavior

The bom provides consistent versions for all of Netty's modules

### Actual behavior

netty-transport-unix-common is using a different (and snapshot) version

### Steps to reproduce

Import the bom and try to resolve netty-transport-unix-common from Maven Central

### Minimal yet complete reproducer code (or URL to code)

N/A

### Netty version

4.1.12.Final

### JVM version (e.g. `java -version`)

N/A

### OS version (e.g. `uname -a`)

N/A


Issue comments:
And now I've noticed that the module name's incorrect. I believe it should be `netty-transport-native-unix-common`. Sorry, if that's the case, I should have spotted it when reviewing https://github.com/netty/netty/pull/6740.
Fixed by https://github.com/netty/netty/pull/6851

Pull request review comments:

Patch that resolved the issue:
diff --git a/bom/pom.xml b/bom/pom.xml
index a0425e225ea..ed7bffe0579 100644
--- a/bom/pom.xml
+++ b/bom/pom.xml
@@ -188,8 +188,8 @@
       </dependency>
       <dependency>
         <groupId>io.netty</groupId>
-        <artifactId>netty-transport-unix-common</artifactId>
-        <version>4.1.12.Final-SNAPSHOT</version>
+        <artifactId>netty-transport-native-unix-common</artifactId>
+        <version>4.1.13.Final-SNAPSHOT</version>
       </dependency>
       <dependency>
         <groupId>io.netty</groupId>


Test patch: