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

ns_server should send 302 reply when view query hits node without any active vbuckets

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: ns_server
    • Security Level: Public
    • Labels:
      None

      Description

      Client's would like to cache list of bucket's nodes. Currently when node is rebalanced out there's period of time when it doesn't have any active vbuckets left. Our view merger cannot deal with that so we currently return 404.

      But SDK folks would like us to handle it similarly to not-my-vbucket at memcached level. And they want to send back 302 with some random node with vbuckets in Location.

      update: I think I wasn't clear enough. 404 is hard to interpret from client perspective. It may mean 'no such ddoc exist' or 'no such bucket exists' or currently 'you cannot query this node'. 302 instead of 404 for such condition would be much clearer signal to client.

        Issue Links

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

          Activity

          alkondratenko Aleksey Kondratenko (Inactive) created issue -
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Field Original Value New Value
          Description Client's would like to cache list of bucket's nodes. Currently when node is rebalanced out there's period of time when it doesn't have any active vbuckets left. Our view merger cannot deal with that so we currently return 404.

          But SDK folks would like us to handle it similarly to not-my-vbucket at memcached level. And they want to send back 302 with some random node with vbuckets in Location.
          Client's would like to cache list of bucket's nodes. Currently when node is rebalanced out there's period of time when it doesn't have any active vbuckets left. Our view merger cannot deal with that so we currently return 404.

          But SDK folks would like us to handle it similarly to not-my-vbucket at memcached level. And they want to send back 302 with some random node with vbuckets in Location.

          update: I think I wasn't clear enough. 404 is hard to interpret from client perspective. It may mean 'no such ddoc exist' or 'no such bucket exists' or currently 'you cannot query this node'. 302 instead of 404 for such condition would be much clearer signal to client.
          Hide
          iryna iryna added a comment - - edited

          verified on build 1854
          change - http://review.couchbase.org/#/c/21657/

          302 is returned.
          iryna@test-ruby01:~/couchbase/testrunner$ curl -v 'http://10.3.121.105:8092/default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0'
          curl: /usr/local/lib/libcurl.so.4: no version information available (required by curl)

          • About to connect() to 10.3.121.105 port 8092 (#0)
          • Trying 10.3.121.105... connected
          • Connected to 10.3.121.105 (10.3.121.105) port 8092 (#0)
            > GET /default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0 HTTP/1.1
            > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.21.4 OpenSSL/1.0.1 zlib/1.2.3.4
            > Host: 10.3.121.105:8092
            > Accept: /
            >
            < HTTP/1.1 302 Moved Temporarily
            < Server: Couchbase Server 2.0.0-1854-rel-enterprise
            < Pragma: no-cache
            < Location: http://10.3.121.104:8092/default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0
            < Date: Tue, 16 Oct 2012 08:54:52 GMT
            < Content-Type: application/json
            < Content-Length: 105
            < Cache-Control: no-cache
            <
          • Connection #0 to host 10.3.121.105 left intact
          • Closing connection #0 {"error":"no_active_vbuckets","reason":"Cannot execute view query since the node has no active vbuckets"}

          But on UI error is not user-friendly: {"error":{"xhrStatus":"error","errMsg":""}}
          attaching screenshot

          Show
          iryna iryna added a comment - - edited verified on build 1854 change - http://review.couchbase.org/#/c/21657/ 302 is returned. iryna@test-ruby01:~/couchbase/testrunner$ curl -v 'http://10.3.121.105:8092/default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0' curl: /usr/local/lib/libcurl.so.4: no version information available (required by curl) About to connect() to 10.3.121.105 port 8092 (#0) Trying 10.3.121.105... connected Connected to 10.3.121.105 (10.3.121.105) port 8092 (#0) > GET /default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0 HTTP/1.1 > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.21.4 OpenSSL/1.0.1 zlib/1.2.3.4 > Host: 10.3.121.105:8092 > Accept: / > < HTTP/1.1 302 Moved Temporarily < Server: Couchbase Server 2.0.0-1854-rel-enterprise < Pragma: no-cache < Location: http://10.3.121.104:8092/default/_design/view1/_view/view1?connection_timeout=60000&limit=10&skip=0 < Date: Tue, 16 Oct 2012 08:54:52 GMT < Content-Type: application/json < Content-Length: 105 < Cache-Control: no-cache < Connection #0 to host 10.3.121.105 left intact Closing connection #0 {"error":"no_active_vbuckets","reason":"Cannot execute view query since the node has no active vbuckets"} But on UI error is not user-friendly: {"error":{"xhrStatus":"error","errMsg":""}} attaching screenshot
          iryna iryna made changes -
          Comment [ verified on build 1854
          change - http://review.couchbase.org/#/c/21657/

          302 is returned. But on UI error is not user-friendly: {"error":{"xhrStatus":"error","errMsg":""}}
          attaching screenshot ]
          iryna iryna made changes -
          Attachment No_active_vbuckets_UI.png [ 15436 ]
          Hide
          alkondratenko Aleksey Kondratenko (Inactive) added a comment -

          Thanks for pointing this out. We'll deal with that.

          Show
          alkondratenko Aleksey Kondratenko (Inactive) added a comment - Thanks for pointing this out. We'll deal with that.
          Hide
          farshid Farshid Ghods (Inactive) added a comment -

          Iryna is going to file a seperate ticket for this issue

          Show
          farshid Farshid Ghods (Inactive) added a comment - Iryna is going to file a seperate ticket for this issue
          farshid Farshid Ghods (Inactive) made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          avsej Sergey Avseyev made changes -
          Link This issue blocks CCBC-169 [ CCBC-169 ]
          alkondratenko Aleksey Kondratenko (Inactive) made changes -
          Link This issue duplicates MB-7661 [ MB-7661 ]

            People

            • Assignee:
              alkondratenko Aleksey Kondratenko (Inactive)
              Reporter:
              alkondratenko Aleksey Kondratenko (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Gerrit Reviews

                There are no open Gerrit changes