Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-922

Replication window size is too small on high latency networks

    Details

    • Type: Bug
    • Status: Done
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.6.0
    • Component/s: replication
    • Labels:

      Description

      By default it is 100 which is too small on high latency networks, e.g. WAN where latency is 100ms.

      In fact, the purpose of this configuration is unclear. It looks like something inherited from Sun DSEE which had a very different LDAP based protocol as well as supporting functionality like prioritized replication. In addition, network bandwidth has improved, as have network protocol stack implementations (e.g. adaptive TCP buffering), so it is unclear whether this functionality is even needed any more (note that DJ does not support prioritized replication).

      For 2.6 we should consider at the very least increasing the window size and/or deprecating it.

      Example #1:

      Given a modrate of of 1000/s
      Given a network latency of 100ms
      Given a window size of 100

      • publisher is sending 1 update / ms
      • after 100ms the receive receives the first update and the publisher blocks (as it has sent 100 updates)
      • after 150ms the receiver sends an ack
      • after 200ms the receiver has received all 100 updates
      • after 250ms the publisher receives the ack for the first 50 updates.

      >>> means they are spending 150ms out of 250ms doing nothing.

      Example #2:

      Given a modrate of of 1000/s (same as before)
      Given a network latency of 100ms (same as before)
      Given a window size of 1000

      • publisher is sending 1 update / ms
      • after 100ms the receive receives the first update
      • after 600ms the receiver sends an ack
      • after 700ms the publisher receives the ack for the first 500 updates (but still has a 300 remaining in its window) and resets its window to 800 (300+500).

      >>> publisher not blocked.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                matthew Matthew Swift
                Reporter:
                matthew Matthew Swift
                Dev Assignee:
                Matthew Swift
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: