KQueue class loading issues with netty 4.2.2.Final

[DCardenasAmp]

I realize the aleph repo isn't officially using 4.2.x yet, but aleph works perfectly for our use cases on 4.2.1.Final at least so figured it'd be helpful to report this issue here.

With 4.2.2.Final, building uberjars on Linux systems throws errors like this:

Syntax error macroexpanding def at (netty.clj:1326:1).
Execution error (IllegalStateException) at io.netty.channel.kqueue.Native/loadNativeLibrary (Native.java:150).
Only supported on OSX/BSD

Looks like the issue is that these functions force KQueue classes to be loaded at build time:

aleph/src/aleph/netty.clj

Lines 1327 to 1332 in bb3a1f1

	(defn ^:no-doc transport-server-channel-class [transport]
	(case transport
	:epoll EpollServerSocketChannel
	:kqueue KQueueServerSocketChannel
	:io-uring IOUringServerSocketChannel
	:nio NioServerSocketChannel))

aleph/src/aleph/netty.clj

Lines 1398 to 1410 in bb3a1f1

	(defn ^:no-doc transport-channel-type [transport]
	(case transport
	:epoll EpollDatagramChannel
	:kqueue KQueueDatagramChannel
	:io-uring IOUringDatagramChannel
	:nio NioDatagramChannel))
	(defn- transport-channel-class [transport]
	(case transport
	:epoll EpollSocketChannel
	:kqueue KQueueSocketChannel
	:io-uring IOUringSocketChannel
	:nio NioSocketChannel))

This starts failing on 4.2.2.Final because that version added some new static fields to AbstractKQueueChannel that force io.netty.channel.kqueue.Native to be loaded here, even on non-OSX systems.

I've reported the root cause upstream in netty/netty#15392 already since this seems like a netty regression (and they've fixed similar issues in the past).

While I wait on a response from the netty maintainers, would the maintainers here be open to a PR to guard against issues like this?

I've worked around this locally by replacing the class names in the functions above with calls like (eval 'io.netty.channel.kqueue.KQueueServerSocketChannel) to ensure that the classes aren't loaded until they're actually needed, but wasn't sure on the right approach to adding a test here since this issue doesn't show up in the netty version currently set in project.clj.

[DerGuteMoritz]

Hi @DCardenasAmp, thanks for your report! This looks like another instance of this issue in the Clojure compiler which we've hit before (the ticket also contains a slightly nicer workaround than using eval). A patch to work around that issue is certainly welcome!

I'm curious: What caused you to update to 4.2 already? Note that 4.1 is still maintained for the time being.

FWIW I plan on updating Aleph to 4.2 proper in the near future anyway (and switch to some of the new APIs).

[arnaudgeiser]

Hello Moritz,

Just for your information, we are also facing the same issue since we bumped to 4.2.
Not super happy with the commit introduced by Netty there: https://github.com/netty/netty/pull/15255/files

For the time being, let's recommend Aleph users to stay on Netty 4.1.

[DerGuteMoritz]

FYI: I filed #760 in the meantime to track updating Aleph to Netty 4.2.x.