[
https://issues.apache.org/jira/browse/QPID-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17407248#comment-17407248
]
Robert Godfrey commented on QPID-8557:
--------------------------------------
Until the data is flushed to disk the fact that it is "committed" doesn't mean
that the commit can't be lost - that is the entire point of the flush to disk.
Only once the flush is confirmed can the broker be assured that the data /
commit will not be lost in the event of (for instance) a power failure.
Seeing 10 flushes for 10 messages for a single thread / single connection is
exactly what I would expect. With 10 separate connections/threads there will
be opportunities to combine the syncs which will optimise the time, but the
actual number of syncs will depend on small timing differences: the absolute
minimum would probably be approx 20 flushes, whereas the worst case would be
100, so the 42-79 range sounds about right.
The change you have proposed would be (in general) unsafe because it would
break the guarantees expected of the broker. There _may_ be cases (depending
on the version of AMQP you are using) where there are optimisations that the
broker currently doesn't make use of (particularly on publishing of messages to
the broker) which could speed those cases up but that would not be changes in
Coalescing Commiter but higher up in the model
> [Broker-J] Batching mode for CoalescingCommitter
> ------------------------------------------------
>
> Key: QPID-8557
> URL: https://issues.apache.org/jira/browse/QPID-8557
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Affects Versions: qpid-java-broker-8.0.5
> Reporter: Daniil Kirilyuk
> Priority: Minor
>
> Although QPID-8547 introduced configurable parameters for
> CoalescingCommitter, BDB log is flushed to disc on every message. That is
> caused by calling future.get() inside of
> org.apache.qpid.server.txn.AsyncCommand.complete(). Such call forces broker
> to wait until CoalescingCommiter calls #CommitThread#processJobs() making the
> operation effectively sync instead of async (every message triggers
> processJobs() and data flush).
> To improve overall performance we suggest to add batching mode for
> CoalescingCommitter, which would consider BDBVirtualHost parameters and flush
> data in chunks of size ${qpid.broker.bdbCommiterNotifyThreshold} or every
> ${qpid.broker.bdbCommiterWaitTimeout} ms (whatever comes first).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
