Bug 1261180

Summary: [Enhancement] Make the journal flush timeout configurable in the C++ broker
Product: Red Hat Enterprise MRG Reporter: Mike Cressman <mcressma>
Component: qpid-cppAssignee: Andrew Stitcher <astitcher>
Status: MODIFIED --- QA Contact: Messaging QE <messaging-qe-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.0CC: astitcher, jross, messaging-qe-bugs, opiske, pematous, zkraus
Target Milestone: 3.2Flags: zkraus: needinfo? (smumford)
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike Cressman 2015-09-08 19:26:51 UTC
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):
qpid-cpp-0.34-3

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: