Bug 1261180 - [Enhancement] Make the journal flush timeout configurable in the C++ broker [NEEDINFO]
[Enhancement] Make the journal flush timeout configurable in the C++ broker
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: 3.2
: ---
Assigned To: Andrew Stitcher
Messaging QE
Depends On:
  Show dependency treegraph
Reported: 2015-09-08 15:26 EDT by Mike Cressman
Modified: 2018-03-06 15:40 EST (History)
10 users (show)

See Also:
Fixed In Version: qpid-cpp-0.34-5
Doc Type: Enhancement
Doc Text:
The qpidd persistent message store flush timeout can be configured using a command line option or using the qpidd configuration file. In previous versions of the product, this time was set at 500ms. The appropriate command line option is: ---- --journal-flush-timeout SECONDS ---- The parameter is in seconds but can be a decimal, and will also accept suffixes to allow specification in seconds (`s`), milliseconds (`ms`), microseconds (`us`) and nanoseconds (`ns`). (this is consistent with the other parameters that can also be times). Setting this option in the qpidd configuration file follows the syntax shown below: ---- journal-flush-timeout=1ms ----
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
zkraus: needinfo? (smumford)

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-6730 None None None Never

  None (edit)
Description Mike Cressman 2015-09-08 15:26:51 EDT
Description of problem:
If clients run in synchronous durable mode (AMQP 1.0 java client for example),
performance can suffer due to long (500 ms) timeout.  (See BZ 1087828)
We propose adding a broker configuration setting so the user can control this timeout.  This may not completely solve the problem, but it will allow some tuning to lessen the problem and will allow for some testing that could be helpful to understanding the issue.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
(See BZ 1087828)

Actual results:
Synchronous durable messaging is very slow (rate can be as slow as 1 per second).

Expected results:
Lower the timeout and see that the java client performs better for synchronous durable messaging.

Additional info:

Note You need to log in before you can comment on or make changes to this bug.