Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-7161

under higher sets per second clients dont get all view results after observing for all mutations

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Incomplete
    • Affects Version/s: 2.0-beta-2
    • Fix Version/s: 2.0
    • Component/s: view-engine
    • Security Level: Public
    • Labels:
      None

      Description

      We have just recently found that under load, doing a series of writes, waiting until they're durable, and then querying a view with stale=false gives incorrect results. I should note that this is definitely tied to throughput load. Under minimal load, it works fine. Under a lot of load, we see the incorrect results. This could be a client issue, but I admit that it sounds more like a server side issue at the moment. We're going to try to reproduce it with another client before raising a server issue. It's JCBC-142 at the moment.

      1. view_results.out
        62 kB
        Deepkaran Salooja
      2. observe-test.php
        3 kB
        Deepkaran Salooja
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        mikew Mike Wiederhold added a comment -

        Please see my comment.

        Show
        mikew Mike Wiederhold added a comment - Please see my comment.
        Hide
        mnunberg Mark Nunberg added a comment -

        You are correct; the logging statement was placed at the wrong location (after any success status, rather than specifically a persisted one), and the persistence check in the php extension code checked against the wrong criteria (typo).

        I'm not sure how the Java client failed, but I can't reproduce it with PHP anymore in light of those items which I've fixed up.

        I've filed a bug in PHP for this (PCBC-148, PCBC-149), and there's already JCBC-142 (from whence the bug originated).

        Additionally, means to test this (be it via the mock, or via the cluster) should be available. In reality there's usually a sub-millisecond time difference between having a key persisted and having it replicated..

        So it seems that thanks to our extra debugging, it's no longer a server issue

        Show
        mnunberg Mark Nunberg added a comment - You are correct; the logging statement was placed at the wrong location (after any success status, rather than specifically a persisted one), and the persistence check in the php extension code checked against the wrong criteria (typo). I'm not sure how the Java client failed, but I can't reproduce it with PHP anymore in light of those items which I've fixed up. I've filed a bug in PHP for this ( PCBC-148 , PCBC-149 ), and there's already JCBC-142 (from whence the bug originated). Additionally, means to test this (be it via the mock, or via the cluster) should be available. In reality there's usually a sub-millisecond time difference between having a key persisted and having it replicated.. So it seems that thanks to our extra debugging, it's no longer a server issue
        Hide
        mikew Mike Wiederhold added a comment -

        Thanks for following up on this and I'm glad we have a fix. The Java client is a separate issue that I will take care it tomorrow. Please close this issue as invalid if there is no server fix needed. If you have any other questions let me know.

        Show
        mikew Mike Wiederhold added a comment - Thanks for following up on this and I'm glad we have a fix. The Java client is a separate issue that I will take care it tomorrow. Please close this issue as invalid if there is no server fix needed. If you have any other questions let me know.
        Hide
        chiyoung Chiyoung Seo added a comment -

        I think we have enough evidence indicating that this issue was NOT caused by the server engine side. The separate bugs were created for client sides.

        Show
        chiyoung Chiyoung Seo added a comment - I think we have enough evidence indicating that this issue was NOT caused by the server engine side. The separate bugs were created for client sides.
        Hide
        ingenthr Matt Ingenthron added a comment -

        Great to know we can put this issue to rest. I'm glad we resolved where it was.

        Mike: thanks for stepping through it and reviewing everything Mark submitted. It surely helped to get everyone looking at the same thing.

        Mark: thanks for repro'ing the Java issue and then continuing to iterate providing enough info so the issue could be definitely identified. Also, great followup by filing the related issues.

        Show
        ingenthr Matt Ingenthron added a comment - Great to know we can put this issue to rest. I'm glad we resolved where it was. Mike: thanks for stepping through it and reviewing everything Mark submitted. It surely helped to get everyone looking at the same thing. Mark: thanks for repro'ing the Java issue and then continuing to iterate providing enough info so the issue could be definitely identified. Also, great followup by filing the related issues.

          People

          • Assignee:
            mnunberg Mark Nunberg
            Reporter:
            farshid Farshid Ghods (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes