Bug 1171358

Hi Noriko,

is there a design doc for this new parameter?
Also shouldn't this bug be an RFE? 

Thanks!

(In reply to Viktor Ashirov from comment #2)
> is there a design doc for this new parameter?
> Also shouldn't this bug be an RFE? 

Thank, Viktor.  You are right.  This is an RFE.

The change is quite small...  The waiting time for the consumer ready used to be hardcoded to 1 second, which could be too long in the advanced network environment.  To improve the throughput of the replication, a new config parameter nsDS5ReplicaWaitForAsyncResults (in milliseconds) is introduced.  The default value is 1 second.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Description: Introducing a config attr nsDS5ReplicaWaitForAsyncResults
to the agreement entry.
  dn: cn=<AGREEMENT>,cn=replica,cn="<SUFFIX>",cn=mapping tree,cn=config
  nsDS5ReplicaWaitForAsyncResults: <integer in millisecond>

Prior to this patch, supplier sleeps 1 second if it finds the response
from consumer is not ready.  1 second could be too long if higher
replication throughput is required.

This patch makes the waiting time configurable, and change the default
to 100 millisecond.  If the attribute nsDS5ReplicaWaitForAsyncResults
does not exist or the value is 0, the default value is set.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Also, filed a doc bug: bz 1258997.

Hi Noriko,

I work on the test suite for this feature.
Can you please clarify some things for me?

My actions to detect the feature operability:
- Setup MMR 3 replica
- Set nsslapd-errorlog-level: 8192 (Replication debugging) for each instance
- Set nsDS5ReplicaWaitForAsyncResults: 5000 for each agreement
- Check, that nsDS5ReplicaWaitForAsyncResults value was set successfully
- Add many entries to the first replica in a short time(I used reproducer.sh from upsteam ticket - https://fedorahosted.org/389/attachment/ticket/47957/reproducer.tar.gz)
- Grep /var/log/dirsrv/slapd-instance/errors for repl5_inc_waitfor_async_results

My result:
cat /var/log/dirsrv/slapd-master1/errors | grep inc_waitfor_async
[14/Sep/2015:11:50:50 +051800] - repl5_inc_waitfor_async_results: 0 6
[14/Sep/2015:11:50:51 +051800] - repl5_inc_waitfor_async_results: 0 6
[14/Sep/2015:11:50:55 +051800] - repl5_inc_waitfor_async_results: 6 6
[14/Sep/2015:11:50:56 +051800] - repl5_inc_waitfor_async_results: 6 6
[14/Sep/2015:11:51:23 +051800] - repl5_inc_waitfor_async_results: 10 13
[14/Sep/2015:11:51:23 +051800] - repl5_inc_waitfor_async_results: 12 13
[14/Sep/2015:11:51:28 +051800] - repl5_inc_waitfor_async_results: 13 13
[14/Sep/2015:11:51:28 +051800] - repl5_inc_waitfor_async_results: 13 13
[14/Sep/2015:11:51:33 +051800] - repl5_inc_waitfor_async_results: 29 32
...

So, as you can see, difference between lines(where last_message_id_received number != last_message_id_sent number) is not always a five seconds.

What could be the issue?
My test plan is not good enough? Or have I found a bug?

Hi simon,

Could it be possible to change the topology to 2-way MMR?

I assume 3-way MMR is configured like this loop?
    Master1 <--> Master2 <--> Master3 <--> Master1
and on Master1, it logs both to-Master2 and to-Master3 which cannot be distinguished in the "repl5_inc_waitfor_async_results: ## ##" log, unfortunately...  (Please ease the expectation to 4 through 6 seconds due to the granularity of the timestamp...)

Ho Noriko,

it makes perfect sense. Thank you!

Now everything has been tested and works properly.

Thank you for the good news, Simon!!
(I'm soooo relieved I did not bring in a regression... ;)

Build tested:
389-ds-base-1.3.4.0-15.el7.x86_64

Test suite for The Upstream:
https://fedorahosted.org/389/attachment/ticket/47957/0001-Ticket-47957-Add-replication-test-suite-for-a-wait-a.patch

Test results:
================================================= test session starts =================================================
platform linux2 -- Python 2.7.5 -- py-1.4.27 -- pytest-2.7.0 -- /usr/bin/python
rootdir: /tmp/ds/dirsrvtests/suites/replication, inifile: 
collected 10 items 

dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_not_int_value PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_multi_value PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr0] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr1] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr2] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_value_check[waitfor_async_attr3] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr0] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr1] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr2] PASSED
dirsrvtests/suites/replication/wait_for_async_feature_test.py::test_behavior_with_value[waitfor_async_attr3] PASSED

============================================= 10 passed in 198.21 seconds =============================================

VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2351.html