Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/47957 Currently, supplier sleeps 1 second if it finds the response from consumer is not ready. {{{ plugins/replication/repl5_inc_protocol.c @@ -485,7 +486,7 @@ repl5_inc_waitfor_async_results(result_data *rd) } PR_Unlock(rd->lock); /* If not then sleep a bit */ DS_Sleep(PR_SecondsToInterval(1)); }}} The attached patch makes it configurable.
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