@clebert Yes, the change introduces a lot of new stuff and it needs to play better with the rest of the system from a user perspective too (definition of properties/configurations...I'm not used to them at all...you've seen my last PR on NettyConnection and you know what I mean: a configuration properties HELL).
@michael As Clebert said we need more integration, unit and performance tests to validate it. For example, the "smart batching" policy (enabled by default now) used to coalesce the fsyncs/msyncs operations seems to be pretty effective from a latency point of view in the most of the cases (100->4k bytes sized messages with 1->64 clients), but requires additional analysis with different load distributions and proper HW to be sure on its effectiveness. >I'm unclear why you’d run or you’re recommending with disabling the disk cache's? You're right, I've missed some context here :P . I've not given that advice from a durability point of view, but I've noticed that the background zeroing of the journal files while under sustained load, could "steal" (vendor and journal size dependent) the write cache buffer to the main writer making it less stable from a latency perspective, especially with long running all out throughput tests. Different vendors implement that cache in very different ways and right now I've not implemented the zeroing so differently from the other 2 journals: memory mapped files are by default lazy zeroed (on *Nix) hence I could avoid any zeroing at all, exploiting additional temporal locality, but it is something that need more tests in order to be configurable and effective from the most of the systems. Anyway I'll be very happy to receive feed-back about its performance with proper hardware, hence thanks :) -- View this message in context: http://activemq.2283324.n4.nabble.com/Paging-tp4724085p4724479.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
