activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nigro_franz <>
Subject Re: Paging
Date Sun, 02 Apr 2017 08:19:38 GMT
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've seen my
last PR on NettyConnection and you know what I mean: a configuration
properties HELL).

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

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:
Sent from the ActiveMQ - Dev mailing list archive at

View raw message