As noted in a related issue (https://issues.jboss.org/browse/ENTMQBR-1184), large messages could lead to leaks native memory while using NIO (https://bugs.openjdk.java.net/browse/JDK-8147468) bringing instability, OOM and higher memory requirements of the broker (as saw in some soak tests).
This is happening on Core due to:

• large message chunking that would leaks on NIO FileChannel thread local cache

This is happening on AMQP, OpenWire due to:

• high number of copies performed inside the broker to perform read/write of the whole large message file (+ the stealth ones performed internally by FileChannel)