[undertow-dev] TransferTo/sendfile Undertow v1.0.x vs 1.1.x

Hi everyone, I wanted to run this 'issue' past the experts, as I've looked into it myself and hit a bit of a dead end. Our application is using Undertow 1.0.17 for serving both static and dynamic Web content. We did some benchmarking early on in the development of our app and got some very impressive results. On a modest server with undertow 1.0.17, using wrk defaults we get around 50k rqsts/s for a 2kb file and about 17k rqsts/s for a 100kb file. So far, so (very) good. I recently tried updating to version 1.1.2 and ran the original tests and got similar results as for v1.0.17 for the 2kb file. For the 100kb file, however the throughput dropped to about 10k rqsts/s. Not the end of the world, I know but I decided to dig around and see what was (or wasn't) going on.... Our app has a sendfile threshold (64k), that above which we use the ResponseChannel 'TransferTo' method, which performs (on Linux anyway) a native zero-copy sendfile operation using the Java NIO FileChannel.transferTo call (which calls into Linux sendfile under the covers if certain conditions are met). In v1.0.x, the native sendfile method (transferTo0) is ultimately invoked to send the content. But in v1.1.x (and 1.2.x also) the transferTo method in the FileChannel instead opts to invoke transferToArbitraryChannel which resorts to a kernel -> user space copy and a not-insignificant drop in throughput. So my question is, is this change across the versions deliberate, a sacrifice for improvements elsewhere - or is it a bug? If it's a bug I'm happy to re-instate the native sendfile functionality myself, but I wanted to check it was an issue first... Thanks in advance for any assistance/advice on this one... David.