It really is a camel bug in the netty impelementation.
I decided to not use camel in that case and fall back to a native netty implementation.
PR: https://github.com/OpenNMS/opennms/pull/1896

I set up a dummy project here: https://github.com/mvrueden/netty-camel-debug
Even with that the issue persists.
I tried various netty and camel versions, but no luck.
This looks to me like a camel problem.

Thanks Markus von Rüden for the efforts, I imagine that this problem occurs due to some residue from some old version of opennms. My opennms has been upgraded since 2008. Maybe something in the database.

I did some digging, but couldn't find the root cause of this problem.
However this is what I observed:

The application keeps running into this section https://github.com/netty/netty/blob/4.1/transport/src/main/java/io/netty/channel/AbstractChannel.java#L869 meaning, the outbound channel is already closed. The next line, which updates the reference counter also throws an exception.

That means, we should always see the "ConnectionClosedException" in combination with "IllegalReferenceCountException".

I debugged a bit further and found out, that the outbound channel is already being closed during reading and found the code responsible for that: https://github.com/netty/netty/blob/4.1/transport/src/main/java/io/netty/channel/nio/AbstractNioByteChannel.java#L155

I am not sure what exactly is causing the channel to be closed right after reading, but if we are able to figure that out, we probably can fix the issue.

I tried to log the procession of each message to verify that no message is processed by multiple threads and can confirm, that at least that is not the case.
Bumping camel and netty versions did not solve the issue (stayed with netty4 though) as well.

Maybe we can implement a simpler message processing for debug purposes and can ensure that it is not caused by our code.

 Hello Ronny Trommer, I have not installed grafana on my server