@clebertsuconic @gaohoward AFAIK you've worked recently on Large messages: please share your thoughts and if you see other points where this improvement should be used.
The optimal solution would be by using [DefaultFileRegion](https://netty.io/4.1/api/io/netty/channel/DefaultFileRegion.html) to zero-copy data through the wire, but it involves to change `Packet` in order to use a `FileRegion` body instead of `byte`: this solution I've proposed seems less invasive, while providing very good perf improvements.
> I think using mapped file will get better performance over the NIO channel read.
@orpiske have some nice idea to test it for sure :P
> It would be better to have a unit test with it. @clebertsuconic wdyt?
If you 2 will vote for the chunked version I will squash the 2 commits and provide a unit test to cover this new implementation: ATM it is just using the tests related to large messages.
> I think so too.. but I would do it in the context of a refactoring in AMQP also
That means that the same large body encoder should be reused for it as well?
@michaelandrepearce Good points: paging (the consuming side) , this PR and a mapped journal should contend the OS page cache , so it depends on the dirty/dirty background ratio and total system memory.
Probably should makes sense to allow this feature to be configurable (and paging as well) in order to avoid contention between them or just tune the OS according (tricky IMO). Wdyt?
@michaelandrepearce I'm thinking with @orpiske which kind of test should make sense in order to emulate the correct use case to be stressed...
Please, can you share your throughts on that?
I'm concerned about how much is OS configuration sensitive running those tests as well
@mtaylor @michaelandrepearce Yep and it isn't changing the way the mapped journal works: it uses a different code path from the journal, without changing the MappedSequentialFile in any of its parts.
I agree that I could provide relative measurements to show which impact it has vs the original version: with @orpiske probably we could start providing some relative numbers before merging anything. @orpiske wdyt?
@michaelandrepearce @mtaylor @clebertsuconic @gaohoward Guys I was looking to the improvements made by this PR and....I found that there is a log of Journal activity with it! I mean....ASYNCIO ones...it makes sense?
That activity seems the bottleneck on consumer side....