Server Selection Algorithm Causes Blocking with Causal Consistency

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Duplicate
    • Priority: Major - P3
    • None
    • Affects Version/s: 3.6.0, 4.0.0
    • Component/s: Concurrency, Performance, Replication
    • None
    • ALL
    • Hide

      Example: a web-application can tolerate some staleness but must have predictably fast response times. It reads some state (RS) which is predicated upon by the next read (R). The server selected for RS (S1) could also respond to R without delay but instead a different server (S2) is selected at random whose replication lags behind S1 and the response is blocked until S2 catches up.

      Show
      Example: a web-application can tolerate some staleness but must have predictably fast response times. It reads some state (RS) which is predicated upon by the next read (R). The server selected for RS (S1)  could  also respond to R without delay but instead a different server (S2) is selected at random whose replication lags behind S1 and the response is blocked until S2 catches up.
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      I previously raised this as an improvement but it may also need to be considered as a bug.

      SERVER-35944 Session Pinning

      Implementation appears to violate updates that were due to the Max Staleness specification on the introduction of causal consistency and there is potential to impact expected performance.

      The server selection algorithm randomly directs reads to different servers which causes blocking if the reads are causally dependent and the selected server has yet to apply the operations depended upon.

            Assignee:
            Unassigned
            Reporter:
            Simon Yarde
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: