[
https://issues.apache.org/jira/browse/AMQ-5603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264257#comment-15264257
]
Gary Tully commented on AMQ-5603:
---------------------------------
[~ceposta] I extended scope to have a preallocate_async option - so that we
fire a job to preallocate the next data file when we rotate. This seems to
reduce latency jitter on publish but it needs validation on real hardware.
On the kernel_copy strategy - I did not see any point to deleting/recreating
the template file so that is changed. Can you peek at that?
In an effort to keep this safe, the sync is very explicit in journal. The whole
class was synchronized which had to change to allow contention on the
nextWriteId between the appender and the async task.
> Consider preallocation of journal files in batch increments
> -----------------------------------------------------------
>
> Key: AMQ-5603
> URL: https://issues.apache.org/jira/browse/AMQ-5603
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Message Store
> Reporter: Christian Posta
> Priority: Minor
> Labels: kahaDB, perfomance
>
> Right now (as of ActiveMQ 5.12 release) we preallocate journal files, but the
> only scope is for entire journal file. The [potential] issue with that is if
> user configures large journal file sizes, we can end up stalling writes
> during log rotation because of the allocation process. There are two ways to
> do the allocation, configurable to do it in userspace, or defer to kernel
> space, but nevertheless it would be good to avoid this issue altogether by
> preallocating in small batch sizes regardless of the journal max file size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
