New native transport for kqueue #6000

Scottmitch · 2016-11-09T20:43:01Z

Motivation:
We currently don't have a native transport which supports kqueue https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2. This can be useful for BSD systems such as MacOS to take advantage of native features, and provide feature parity with the Linux native transport.

Modifications:

Make a new transport-native-unix-common module with all the java classes and JNI code for generic unix items. This module will build a static library for each unix platform, and included in the dynamic libraries used for JNI (e.g. transport-native-epoll, and eventually kqueue).
Make a new transport-native-unix-common-tests module where the tests for the transport-native-unix-common module will live. This is so each unix platform can inherit from these test and ensure they pass.
Add a new transport-native-kqueue module which uses JNI to directly interact with kqueue

Result:
JNI support for kqueue.
Fixes #2448
Fixes #4231

Scottmitch · 2016-11-09T20:46:26Z

@normanmaurer @nmittler @marcuslinke @timothyjward @shpikat @caarlos0 @ninja- @rnorth @ndeloof @slandelle @headius (everyone on the related issues) - PTAL.

There is a large amount of code here ... sorry about that. However it would be nice to get some miles on it and gain more confidence and uncover any issues ASAP.

There is also some duplication in the Channel hierarchy between EPOLL and KQUEUE. It is not possible for them to share a common hierarchy so for now I think its is OK to keep the duplication and look to improve/consolidate later.

slandelle · 2016-11-09T20:49:24Z

🎉 🎉 🎉 I'll give it a try as soon as I can (will probably be next week). Thanks a lot!

Scottmitch · 2016-11-09T20:53:53Z

Build failure seems to be related to not being able to find the artifact from a new sub-module introduced in this PR. I recall seeing this issue in the past on the CI servers, and thought we changed the build order or added an extra build pass to resolve this type of issues ... @trustin @normanmaurer do you recall?

Could not resolve dependencies for project io.netty:netty-transport-native-epoll:jar:4.1.7.Final-SNAPSHOT: Could not find artifact io.netty:netty-transport-native-unix-common:jar:linux-x86_64:4.1.7.Final-SNAPSHOT

vietj · 2016-11-09T22:38:33Z

nice to see that !

Scottmitch · 2016-11-09T23:36:08Z

@normanmaurer @trustin - Looks like we do the following on the build servers:

$mvn clean validate
<will fail if new modules are added in the PR>
$mvn test

can we instead do:

$mvn clean install -DskipTests
$mvn test

marcuslinke · 2016-11-10T06:18:33Z

@Scottmitch Sounds great! Will try it this weekend. Thanks for your effort!

normanmaurer · 2016-11-10T06:49:46Z

@Scottmitch we not want to do an "install" as this will install "changes" that may break other builds on the same host. I wonder if we can't tell maven to just resolve this somehow internally or if we can't tell maven to use an temporary local maven repository.

normanmaurer · 2016-11-10T06:50:46Z

Let me investigate

normanmaurer · 2016-11-10T07:05:50Z

@Scottmitch ok seems like I can use a custom local maven repos... Let me try this out on the CI and kick off another build. Also thanks for this "massive" work :)

normanmaurer · 2016-11-10T08:05:15Z

@Scottmitch for the record the build is successful locally here :)

normanmaurer · 2016-11-10T08:19:42Z

@Scottmitch ok it should now work on the CI as soon as the build is fixed for linux.

The problem is it builds and installs this one:
netty-transport-native-unix-common-4.1.7.Final-SNAPSHOT-linux-x86_64-fedora.jar

But it looks for:
netty-transport-native-unix-common:jar:linux-x86_64:4.1.7.Final-SNAPSHOT

The unix-common should not add -fedora to it.

Please fix and the build should work :)

Scottmitch · 2016-11-10T17:17:02Z

@normanmaurer - I actually want the classifier on the artifact ... but I was just inconsistently using epoll.classifier and os.detected.classifier inconsistently. That should now be fixed.

However it looks like the build server is still doing the clean validate ... do I have to open a new PR to get the changes?

normanmaurer · 2016-11-10T18:05:00Z

@Scottmitch let me check the config again... maybe I missed to change it to install but at least it uses the local repository now.

Why you need to use the "-fedora" classifier ? We not used it before in the epoll transport as it works on fedora and debian etc....

Scottmitch · 2016-11-10T19:18:38Z

Why you need to use the "-fedora" classifier

Not specifically the "-fedora" type classifier ... just the same classifier used by the epoll module (e.g. <epoll.classifier>${os.detected.name}-${os.detected.arch}</epoll.classifier>)

marcuslinke · 2016-11-11T07:51:24Z

When trying to bootstrap my application like this:

EventLoopGroup nioEventLoopGroup = new KQueueEventLoopGroup(0,
                new DefaultThreadFactory(threadPrefix));

            bootstrap.group(nioEventLoopGroup).channel(KQueueDomainSocketChannel.class)
                    .handler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(final SocketChannel channel) throws Exception {
                            channel.pipeline().addLast(new LoggingHandler(getClass()));
                            channel.pipeline().addLast(new HttpClientCodec());
                        }
                    });

            return nioEventLoopGroup;

I get an exception

java.lang.UnsatisfiedLinkError: failed to load the required native library
    at io.netty.channel.kqueue.KQueue.ensureAvailability(KQueue.java:70)
    at io.netty.channel.kqueue.KQueueEventLoopGroup.<clinit>(KQueueEventLoopGroup.java:35)
    at com.github.dockerjava.netty.NettyDockerCmdExecFactory$UnixDomainSocketInitializer.init(NettyDockerCmdExecFactory.java:223)
    at com.github.dockerjava.netty.NettyDockerCmdExecFactory.init(NettyDockerCmdExecFactory.java:195)
    at com.github.dockerjava.core.TestDockerCmdExecFactory.init(TestDockerCmdExecFactory.java:91)
    at com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:161)
    at com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:45)
    at com.github.dockerjava.client.AbstractDockerClientTest.beforeTest(AbstractDockerClientTest.java:57)
    at com.github.dockerjava.netty.exec.VersionCmdExecTest.beforeTest(VersionCmdExecTest.java:22)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
    at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514)
    at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215)
    at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
    at org.testng.TestRunner.beforeRun(TestRunner.java:656)
    at org.testng.TestRunner.run(TestRunner.java:624)
    at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
    at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
    at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
    at org.testng.SuiteRunner.run(SuiteRunner.java:268)
    at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
    at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
    at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
    at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
    at org.testng.TestNG.run(TestNG.java:1064)
    at org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:126)
    at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:137)
    at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:58)
Caused by: java.lang.NoSuchMethodError: Method io.netty.channel.unix.Socket.recvFd(I)I not found
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1851)
    at java.lang.Runtime.load0(Runtime.java:795)
    at java.lang.System.load(System.java:1062)
    at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:36)
    at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:255)
    at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:222)
    at io.netty.channel.kqueue.Native.loadNativeLibrary(Native.java:103)
    at io.netty.channel.kqueue.Native.<clinit>(Native.java:50)
    at io.netty.channel.kqueue.KQueue.<clinit>(KQueue.java:33)

Maybe have declared the wrong dependencies ?

<dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-epoll</artifactId>
            <version>${netty.version}</version>
            <classifier>linux-x86_64</classifier>
            <exclusions>
                <exclusion>
                    <groupId>io.netty</groupId>
                    <artifactId>netty-transport-native-unix-common</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-kqueue</artifactId>
            <version>${netty.version}</version>
            <classifier>osx-x86_64</classifier>
            <exclusions>
                <exclusion>
                    <groupId>io.netty</groupId>
                    <artifactId>netty-transport-native-unix-common</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-unix-common</artifactId>
            <version>${netty.version}</version>
        </dependency>

normanmaurer · 2016-11-11T07:58:22Z

You also need to specify the qualifier for the unix-common dependency AFAIC

Am 11.11.2016 um 08:51 schrieb marcuslinke notifications@github.com:

When trying to bootstrap my application like this:

EventLoopGroup nioEventLoopGroup = new KQueueEventLoopGroup(0,
new DefaultThreadFactory(threadPrefix));
        bootstrap.group(nioEventLoopGroup).channel(KQueueDomainSocketChannel.class)
                .handler(new ChannelInitializer<SocketChannel>() {
                    @Override
                    protected void initChannel(final SocketChannel channel) throws Exception {
                        channel.pipeline().addLast(new LoggingHandler(getClass()));
                        channel.pipeline().addLast(new HttpClientCodec());
                    }
                });

        return nioEventLoopGroup;
I get an exception

java.lang.UnsatisfiedLinkError: failed to load the required native library
at io.netty.channel.kqueue.KQueue.ensureAvailability(KQueue.java:70)
at io.netty.channel.kqueue.KQueueEventLoopGroup.(KQueueEventLoopGroup.java:35)
at com.github.dockerjava.netty.NettyDockerCmdExecFactory$UnixDomainSocketInitializer.init(NettyDockerCmdExecFactory.java:223)
at com.github.dockerjava.netty.NettyDockerCmdExecFactory.init(NettyDockerCmdExecFactory.java:195)
at com.github.dockerjava.core.TestDockerCmdExecFactory.init(TestDockerCmdExecFactory.java:91)
at com.github.dockerjava.core.DockerClientImpl.withDockerCmdExecFactory(DockerClientImpl.java:161)
at com.github.dockerjava.core.DockerClientBuilder.build(DockerClientBuilder.java:45)
at com.github.dockerjava.client.AbstractDockerClientTest.beforeTest(AbstractDockerClientTest.java:57)
at com.github.dockerjava.netty.exec.VersionCmdExecTest.beforeTest(VersionCmdExecTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:86)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:514)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:215)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
at org.testng.TestRunner.beforeRun(TestRunner.java:656)
at org.testng.TestRunner.run(TestRunner.java:624)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:366)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319)
at org.testng.SuiteRunner.run(SuiteRunner.java:268)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1244)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
at org.testng.TestNG.run(TestNG.java:1064)
at org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:126)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:137)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:58)
Caused by: java.lang.NoSuchMethodError: Method io.netty.channel.unix.Socket.recvFd(I)I not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1851)
at java.lang.Runtime.load0(Runtime.java:795)
at java.lang.System.load(System.java:1062)
at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:36)
at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:255)
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:222)
at io.netty.channel.kqueue.Native.loadNativeLibrary(Native.java:103)
at io.netty.channel.kqueue.Native.(Native.java:50)
at io.netty.channel.kqueue.KQueue.(KQueue.java:33)
Maybe have declared the wrong dependencies ?
io.netty netty-transport-native-epoll ${netty.version} linux-x86_64 io.netty netty-transport-native-unix-common io.netty netty-transport-native-kqueue ${netty.version} osx-x86_64 io.netty netty-transport-native-unix-common io.netty netty-transport-native-unix-common ${netty.version} — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

marcuslinke · 2016-11-11T08:06:15Z

@normanmaurer Using classifier 'osx-x86_64' I get the same exception.

Scottmitch · 2016-11-11T16:58:57Z

@marcuslinke - netty-transport-native-unix-common is a transitive dependency that you shouldn't have to explicitly include in your application. This is where all the unix general stuff from the transport-native-epoll module moved to so it could be shared with transport-native-kqueue. The goal is that you should be able to include the kqueue module the same way you include the epoll module http://netty.io/wiki/native-transports.html#using-the-native-transport.

While its in PR form make sure you do the following:

$ cd netty
$ git fetch <my remote repo>
$ git checkout <this branch>
$ mvn clean install -DskipTests

And your netty.version property should be set to 4.1.7.Final-SNAPSHOT.

Let me know if there are still issues after trying this.

This is how the netty-all module include the netty-transport-native-kqueue module https://github.com/netty/netty/pull/6000/files#diff-01b5eceed5fb6499e99a42e711695648R114. Which reminds me the netty-all jar packing will have to change now that we support different platforms. Here are some options:

Instead of netty-all repackaging all jars it just references other modules (we had an issue discussing this but I can't find it).
Publish different netty-all components with the os.classifier qualifier. netty-all with no classier would keep pointing to the epoll module for backwards compatibility.
Get rid of netty-all (not so backwards compatible).

marcuslinke · 2016-11-11T17:40:05Z

@Scottmitch The problem is that I've to support both systems (linux and macos), so how this should work. As I understand the os-maven-plugin detects the build systems OS so the dependencies classifier is set to 'macos' effectively. Therefore I decided to hardcode the classifiers in the POM somehow. Any ideas?

marcuslinke · 2016-11-11T17:55:47Z

@Scottmitch Why netty-transport-native-unix-common needs a qualifier? Is it really needed?

Scottmitch · 2016-11-11T17:56:23Z

The problem is that I've to support both systems (linux and macos), so how this should work.

Depends how you want to achieve this.

isolate all your epoll or kqueue code in a module that is conditionally declared as a dependency in the pom.
Always include them both, and just check KQueue.isAvailable() or Epoll.isAvailable() before you use either.

OS so the dependencies classifier is set to 'macos' effectively

Perhaps but is their a reasons to hardcode and not just use the recommended approach?

Scottmitch · 2016-11-11T18:00:10Z

netty-transport-native-unix-common also builds a native library ... although it is static and included in the kqueue's and epoll's native library at build time. It may be possible to omit the clarifier I would prefer not to as it clarifies which platform the artifact was built on, and incase there needs to be any differences between platforms we can accommodate.

marcuslinke · 2016-11-11T19:40:32Z

@Scottmitch Your branch compiles and installs fine here. But even when I do as suggested I get the same exception...

java.lang.UnsatisfiedLinkError: failed to load the required native library

<dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-epoll</artifactId>
            <version>4.1.7.Final-SNAPSHOT</version>
            <classifier>linux-x86_64</classifier>
        </dependency>
        <dependency>
            <groupId>io.netty</groupId>
            <artifactId>netty-transport-native-kqueue</artifactId>
            <version>4.1.7.Final-SNAPSHOT</version>
            <classifier>osx-x86_64</classifier>
        </dependency>

marcuslinke · 2016-11-11T19:52:30Z

@Scottmitch You said the native library libnetty-unix-common.a is used only at compile time of the epoll and kqueue modules. Maybe there is something wrong in my local build so this library is linked dynamically and missing at runtime?

dannyferreira · 2017-03-16T18:36:26Z

I cloned the PR and got Unix Domain Sockets running on my Mac via kqueue! Thank you guys for your great work :)

I ran into an issue during shutdown though. I'm not sure if it is because I am using Netty incorrectly, please forgive my ignorance if that is the case.

Our shutdown logic for a Unix domain socket server is:

eventLoop.shutdownGracefully();
try {
    channel.closeFuture().sync();
}
catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}

where eventLoop is of type KQueueEventLoopGroup and channel is of type KQueueServerDomainSocketChannel.

This same logic worked for Epoll running on Linux. But when I tried the above with kqueue, it hangs indefinitely on the sync() part of channel.closeFuture().sync();.

Scottmitch · 2017-03-28T02:41:28Z

@dannyferreira - Can you try and reverse the order in which you shutdown the event loop and close the channel? The channel may need to use the event loop for shutdown operations.

Scottmitch · 2017-03-28T17:09:06Z

build failure unrelated and captured in issue #6577

dannyferreira · 2017-03-29T15:55:27Z

@Scottmitch - closing the channel before shutting down the event loop seems to work well for both kqueue and epoll. Thanks!

Scottmitch · 2017-03-31T00:52:26Z

@normanmaurer - Any objections to merging this? I'm not sure that anyone has actually reviewed the code. We need to coordinate the release cycle and builds on the CI servers.

Release Cycle

I'm not very familiar with how the maven release process works but IIRC we need to do something like the following:

On linux: mvn clean install

either publish available artifacts directly from this machine, or copy artifacts over the machine in step (2))

On Mac: mvn clean install -Duber

If we released in step (1) we should only have to build/release transport-native-kqueue, all, and tarball.

It doesn't matter which platform is built first but the -Duber will build netty-all and depends upon all native libraries being available. IIRC we do something similar for the release of tcnative which includes jars for all the different platforms? We should be able to do something similar here.

CI server PR builds

We need to build PRs on MacOS and Linux (to some degree). It would be nice if we could just build the kqueuebits on MacOS and build the rest on Linux (since we have more Linux CI servers). I don't have much visibility into the CI configuration so I'm not sure how to accomplish this.

fenik17 · 2017-03-31T05:29:12Z

transport-native-kqueue/src/main/java/io/netty/channel/kqueue/KQueueDatagramChannel.java

+
+            try {
+                boolean done = false;
+                for (int i = config().getWriteSpinCount() - 1; i >= 0; i--) {


We might avoid subtraction -1 for the any loops with *SpinCount (where i don't use inside),
if change i >= 0 to i > 0:
for (int i = config().getWriteSpinCount(); i > 0; i--)

(But this is only a matter of style.)

This applies not only to the specified line. Some other loops in this PR are iterated by writeSpinCount. To be consistent, it would be nice to change them too :)

tejksat · 2017-03-31T12:57:18Z

@Scottmitch please see the comment: Scottmitch#1 (comment)

lucboutier · 2017-04-12T07:29:38Z

@Scottmitch Managed to build and run your kqueue transport and run it with docker java but seems it fails on one of my colleagues machine (he didn't build your branch but just reused the jar):

dyld: lazy symbol binding failed: Symbol not found: _netty_unix_util_parse_package_prefix
Referenced from: /private/var/folders/dc/_328f1bn5zggz0xm2ztxxfmr0000gn/T/libnetty-transport-native-kqueue4910433518549296650.dylib
Expected in: flat namespace

Any idea ?

Motivation: We currently don't have a native transport which supports kqueue https://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2. This can be useful for BSD systems such as MacOS to take advantage of native features, and provide feature parity with the Linux native transport. Modifications: - Make a new transport-native-unix-common module with all the java classes and JNI code for generic unix items. This module will build a static library for each unix platform, and included in the dynamic libraries used for JNI (e.g. transport-native-epoll, and eventually kqueue). - Make a new transport-native-unix-common-tests module where the tests for the transport-native-unix-common module will live. This is so each unix platform can inherit from these test and ensure they pass. - Add a new transport-native-kqueue module which uses JNI to directly interact with kqueue Result: JNI support for kqueue. Fixes netty#2448 Fixes netty#4231

Scottmitch · 2017-05-03T16:54:25Z

4.1 (3cc4052)

Scottmitch · 2017-05-03T17:04:38Z

@lucboutier - What version of macOS was the artifact built on, and what version of macOS are you trying to use the artifact on? Now that the PR has been merged can you open an issue?

marcuslinke · 2017-06-09T19:57:02Z

@Scottmitch Tried to use kqueue native transport under MacOS 10.11.6 and got

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /private/var/folders/y3/8mx9s87n01942z74s5wjsxjw0000hb/T/libnetty-transport-native-kqueue8841250350785055197.dylib (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib

Any idea if this could be fixed somehow?

marcuslinke · 2017-06-09T20:27:47Z

Created an issue for it: #6837

Scottmitch added the feature label Nov 9, 2016

Scottmitch self-assigned this Nov 9, 2016

This was referenced Nov 9, 2016

Add kqueue channel implementation #2448

Closed

Unix domain sockets coupled to epoll #4231

Closed

Scottmitch force-pushed the kqueue branch from 2811f6c to 798e3eb Compare November 10, 2016 17:06

Scottmitch force-pushed the kqueue branch from 798e3eb to 2185928 Compare November 10, 2016 18:41

Scottmitch force-pushed the kqueue branch 2 times, most recently from 7885fb8 to e21dab3 Compare March 28, 2017 02:40

This was referenced Mar 28, 2017

"Symbol not found: _clock_gettime" error on the runtime fixed on OS X prior to 10.12 when Netty is compiled on OS X 10.12 Scottmitch/netty#1

Closed

HTTP/2 unit test LocalChannel ByteBuf leak #6577

Closed

Scottmitch mentioned this pull request Mar 28, 2017

Allow to configure a maximum select timeout / epoll wait timeout #6297

Closed

Scottmitch force-pushed the kqueue branch from e21dab3 to ff980f1 Compare March 31, 2017 00:40

fenik17 reviewed Mar 31, 2017

View reviewed changes

Scottmitch force-pushed the kqueue branch 2 times, most recently from 189714e to 4708cb3 Compare March 31, 2017 22:56

Scottmitch force-pushed the kqueue branch from 4708cb3 to e1e39b7 Compare April 21, 2017 03:08

Scottmitch mentioned this pull request Apr 27, 2017

netty-all causes classpath problems #4671

Closed

Scottmitch force-pushed the kqueue branch 2 times, most recently from eb3c860 to 15b46ab Compare May 3, 2017 14:28

Scottmitch force-pushed the kqueue branch from 15b46ab to 4b55ff5 Compare May 3, 2017 14:35

Scottmitch closed this May 3, 2017

Scottmitch deleted the kqueue branch May 3, 2017 16:54

normanmaurer added this to the 4.1.11.Final milestone May 12, 2017

mp911de mentioned this pull request May 12, 2017

Add support for kqueue transport redis/lettuce#539

Closed

New native transport for kqueue #6000

New native transport for kqueue #6000

Conversation

Scottmitch commented Nov 9, 2016

Scottmitch commented Nov 9, 2016 • edited Loading

slandelle commented Nov 9, 2016

Scottmitch commented Nov 9, 2016

vietj commented Nov 9, 2016

Scottmitch commented Nov 9, 2016

marcuslinke commented Nov 10, 2016

normanmaurer commented Nov 10, 2016

normanmaurer commented Nov 10, 2016

normanmaurer commented Nov 10, 2016

normanmaurer commented Nov 10, 2016

normanmaurer commented Nov 10, 2016

Scottmitch commented Nov 10, 2016 • edited Loading

normanmaurer commented Nov 10, 2016

Scottmitch commented Nov 10, 2016

marcuslinke commented Nov 11, 2016

normanmaurer commented Nov 11, 2016

marcuslinke commented Nov 11, 2016

Scottmitch commented Nov 11, 2016 • edited Loading

marcuslinke commented Nov 11, 2016

marcuslinke commented Nov 11, 2016

Scottmitch commented Nov 11, 2016 • edited Loading

Scottmitch commented Nov 11, 2016

marcuslinke commented Nov 11, 2016 • edited Loading

marcuslinke commented Nov 11, 2016

dannyferreira commented Mar 16, 2017

Scottmitch commented Mar 28, 2017

Scottmitch commented Mar 28, 2017 • edited Loading

dannyferreira commented Mar 29, 2017

Scottmitch commented Mar 31, 2017

Release Cycle

CI server PR builds

fenik17 Mar 31, 2017 • edited Loading

Choose a reason for hiding this comment

Scottmitch Mar 31, 2017

Choose a reason for hiding this comment

fenik17 Mar 31, 2017

Choose a reason for hiding this comment

tejksat commented Mar 31, 2017

lucboutier commented Apr 12, 2017

Scottmitch commented May 3, 2017

Scottmitch commented May 3, 2017

marcuslinke commented Jun 9, 2017

marcuslinke commented Jun 9, 2017

Scottmitch commented Nov 9, 2016 •

edited

Loading

Scottmitch commented Nov 10, 2016 •

edited

Loading

Scottmitch commented Nov 11, 2016 •

edited

Loading

Scottmitch commented Nov 11, 2016 •

edited

Loading

marcuslinke commented Nov 11, 2016 •

edited

Loading

Scottmitch commented Mar 28, 2017 •

edited

Loading

fenik17 Mar 31, 2017 •

edited

Loading