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

if flush times out final stage (janitor creating vbuckets back) it returns success causing clients to see TMPFAIL after flush succeeds (WAS: there are reports that even after invoking FLUSH nodes return TMPFAIL...)

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-beta-2, 2.0.1, 2.1.0
    • Fix Version/s: bug-backlog
    • Component/s: ns_server
    • Security Level: Public
    • Triage:
      Triaged
    • Is this a Regression?:
      Yes

      Description

      "reported by SDK team"
      After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.

      update:

      I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.

      further update:

      I disagree on the "always be able to handle TMPFAIL", especially in the case of running tests at the SDK side. At the moment, we ask our users to handle tmpfail directly. That's intentional and seems to make sense as a pressure relief valve for steady state, but between these flushes and especially from unit tests, it'd be best if the cluster could just block either the operation request or the flush response until complete.

      Raising this to major owing to end-user reports of trouble here.

      1. test.rb
        0.3 kB
        Sergey Avseyev
      2. test.txt
        0.4 kB
        Sergey Avseyev

        Issue Links

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          farshid Farshid Ghods (Inactive) created issue -
          ingenthr Matt Ingenthron made changes -
          Field Original Value New Value
          Assignee Deepkaran Salooja [ deepkaran.salooja ] Sergey Avseyev [ avsej ]
          avsej Sergey Avseyev made changes -
          Attachment test.txt [ 15772 ]
          Attachment test.rb [ 15773 ]
          avsej Sergey Avseyev made changes -
          Comment [ issue still there ]
          steve Steve Yen made changes -
          Assignee Sergey Avseyev [ avsej ] Aleksey Kondratenko [ alkondratenko ]
          Fix Version/s .next [ 10342 ]
          Fix Version/s 2.0 [ 10114 ]
          Affects Version/s 2.0-beta-2 [ 10385 ]
          steve Steve Yen made changes -
          Labels 2.0-release-notes
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s .next [ 10342 ]
          Resolution Duplicate [ 3 ]
          avsej Sergey Avseyev made changes -
          Link This issue duplicates MB-6232 [ MB-6232 ]
          ingenthr Matt Ingenthron made changes -
          Assignee Aleksey Kondratenko [ alkondratenko ] Matt Ingenthron [ ingenthr ]
          ingenthr Matt Ingenthron made changes -
          Planned End (re-schedule end date based on new assignee)
          ingenthr Matt Ingenthron made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Resolution Duplicate [ 3 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Assignee Matt Ingenthron [ ingenthr ] Aleksey Kondratenko [ alkondratenko ]
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Planned End (re-schedule end date based on new assignee)
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Summary there are reports that even after invoking FLUSH nodes return TMPFAIL ( spec says when flush returns node should be ready ) if flush times out final stage (janitor creating vbuckets back) it returns success causing clients to see TMPFAIL after flush succeeds (WAS: there are reports that even after invoking FLUSH nodes return TMPFAIL...)
          Affects Version/s 2.0.1 [ 10399 ]
          Affects Version/s 2.0.2 [ 10418 ]
          Priority Major [ 3 ] Minor [ 4 ]
          Description "reported by SDK team"
          After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.
          "reported by SDK team"
          After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.

          update:

          I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.
          Component/s couchbase-bucket [ 10173 ]
          ingenthr Matt Ingenthron made changes -
          Description "reported by SDK team"
          After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.

          update:

          I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.
          "reported by SDK team"
          After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.

          update:

          I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.

          further update:

          I disagree on the "always be able to handle TMPFAIL", especially in the case of running tests at the SDK side. At the moment, we ask our users to handle tmpfail directly. That's intentional and seems to make sense as a pressure relief valve for steady state, but between these flushes and especially from unit tests, it'd be best if the cluster could just block either the operation request or the flush response until complete.

          Raising this to major owing to end-user reports of trouble here.
          ingenthr Matt Ingenthron made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Labels 2.0-release-notes ns_server-story
          maria Maria McDuff (Inactive) made changes -
          Fix Version/s 3.0 [ 10414 ]
          maria Maria McDuff (Inactive) made changes -
          Link This issue relates to MB-8956 [ MB-8956 ]
          ingenthr Matt Ingenthron made changes -
          Labels ns_server-story customer ns_server-story
          maria Maria McDuff (Inactive) made changes -
          Fix Version/s 2.5.0 [ 11200 ]
          Fix Version/s 3.0 [ 10414 ]
          maria Maria McDuff (Inactive) made changes -
          Fix Version/s 3.0 [ 10414 ]
          Fix Version/s 2.5.0 [ 11200 ]
          anil Anil Kumar made changes -
          Link This issue duplicates MB-6232 [ MB-6232 ]
          maria Maria McDuff (Inactive) made changes -
          Triage Untriaged [ 10351 ]
          maria Maria McDuff (Inactive) made changes -
          Triage Untriaged [ 10351 ] Triaged [ 10350 ]
          maria Maria McDuff (Inactive) made changes -
          Assignee Aleksey Kondratenko [ alkondratenko ] Maria McDuff [ maria ]
          Fix Version/s bug-backlog [ 11600 ]
          Fix Version/s 3.0 [ 10414 ]
          Triage Triaged [ 10350 ] Untriaged [ 10351 ]
          anil Anil Kumar made changes -
          Assignee Maria McDuff [ maria ] Aleksey Kondratenko [ alkondratenko ]
          Is this a Regression? Yes [ 10450 ]
          wayne Wayne Siu made changes -
          Assignee Aleksey Kondratenko [ alkondratenko ] Cihan Biyikoglu [ cihan ]
          wayne Wayne Siu made changes -
          Triage Untriaged [ 10351 ] Triaged [ 10350 ]

            People

            • Assignee:
              cihan Cihan Biyikoglu (Inactive)
              Reporter:
              farshid Farshid Ghods (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Gerrit Reviews

                There are no open Gerrit changes