Feedback for io_uring native transport

Hi! as you told here

We’d love to hear from you how io_uring works out for you.

So I came here to share a bit of our experience: First of all, thanks for this work, at the end of the day we were able to set everything up, it seems to be working and it reduces latency on our workloads by ~10-15%, cool! Special thanks for the flexibility, it’s nice that one developer can work on Linux and use io_uring at the same time when another one can use Mac OS and falls back to Epoll or other transport.

But one thing works not really great: on my end, I have

uname -a
Linux 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 08:55:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

and our tests hang from time to time on my box with a log like this

## Lettuce Native Transports:
   --> io_uring availability: true
   --> epoll    availability: true

<some other logs here and at the moment we make a real connection to Redis:>

Unable to connect to [redis://127.0.0.1:5982]
java.lang.IllegalStateException: failed to create a child event loop
	at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:88) ~[netty-common-4.1.65.Final.jar:4.1.65.Final]
	... bla-bla-bla a lot of stracktraces here 

Caused by: java.lang.RuntimeException: failed to create io_uring ring fd Cannot allocate memory
	at io.netty.incubator.channel.uring.Native.ioUringSetup(Native Method) ~[netty-incubator-transport-native-io_uring-0.0.5.Final-linux-x86_64.jar:0.0.5.Final]
	at io.netty.incubator.channel.uring.Native.createRingBuffer(Native.java:155) ~[netty-incubator-transport-native-io_uring-0.0.5
	... over 9000 more

the first 3 lines of the log above stand for code

LOG.info("## Lettuce Native Transports:");
LOG.info("   --> io_uring availability: {}", IOUringProvider.isAvailable());
LOG.info("   --> epoll    availability: {}", Epoll.isAvailable());

So, from time to time, Native transport can allocate io_uring, but the next moment it can’t. I saw a note on the netty Readme page about that, but anyhow, seems like the transport check is not sufficient. For some colleagues of mine with a newer kernel, it works just fine.

I also saw that there is 0.0.6 version for netty transport I built it manually and seems like with this version, it works better, cos there is a kernel check > 5.9

Unfortunately, there is no 0.0.6 version in maven, so I can’t verify its behaviour on some test env. I thought about using this issue as a reference for the netty guys why do I ask to upload the 0.0.6 version on maven.

Thanks once again, I would love to hear any thoughts about this one.

[normanmaurer]

@izemlyanskiy all the kernel release before 5.9 had some features missing or bugs that basically resulted in incorrect behaviour.

[mp911de]

Closing that ticket, the dependency upgrade is addressed with #1798.