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

"flush_all" does not clear "curr_items"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Resolution: Won't Fix
    • Affects Version/s: 1.6.0 beta4
    • Fix Version/s: 1.6.0 GA
    • Component/s: couchbase-bucket
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      Steps to reproduce:
      -Setup memcached bucket type
      -Put in item
      -See curr_items incrememnt
      -Execute "flush_all"
      -See curr_items stay the same
      -Try to retrieve item
      -"get" returns NULL
      -Now "curr_items" is decrememented

      As with Membase, flush_all should reset the item count.

        Attachments

          Issue Links

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

            Activity

            Hide
            dustin@sallings.org Dustin Sallings (Inactive) added a comment -

            This just isn't possible to be done concurrently.

            flush_all is an atomic, non-blocking operation. The count is when items report in and stuff. A flush_all that reduced the count can't be atomic because it'd have to touch every item and it'd effectively have to stop the server to do it (or use more memory).

            Membase does it a slow way by slicing up the hash tables (there are lots of them for various vbuckets) and locking to drop data in a loop. flush_all in this way isn't fast and is kind of disruptive to the server, but it's expecting that kind of thing to happen periodically since we do have more things we do to take care of data since it's persistent and what-not.

            Maybe in the future when we have reusable slabs we could find a way to get closer, but in the meantime, it's a tradeoff for speed in such a way that memcached won't be able to take the changes back up.

            Show
            dustin@sallings.org Dustin Sallings (Inactive) added a comment - This just isn't possible to be done concurrently. flush_all is an atomic, non-blocking operation. The count is when items report in and stuff. A flush_all that reduced the count can't be atomic because it'd have to touch every item and it'd effectively have to stop the server to do it (or use more memory). Membase does it a slow way by slicing up the hash tables (there are lots of them for various vbuckets) and locking to drop data in a loop. flush_all in this way isn't fast and is kind of disruptive to the server, but it's expecting that kind of thing to happen periodically since we do have more things we do to take care of data since it's persistent and what-not. Maybe in the future when we have reusable slabs we could find a way to get closer, but in the meantime, it's a tradeoff for speed in such a way that memcached won't be able to take the changes back up.
            Hide
            dustin@sallings.org Dustin Sallings (Inactive) added a comment -
            Show
            dustin@sallings.org Dustin Sallings (Inactive) added a comment -
            Hide
            sharon.barr@northscale.com sharon.barr@northscale.com added a comment -

            Btw, the memory byte used also behaves likes item count. going down only if you try to get these items (and fail).

            Show
            sharon.barr@northscale.com sharon.barr@northscale.com added a comment - Btw, the memory byte used also behaves likes item count. going down only if you try to get these items (and fail).
            Hide
            dustin@sallings.org Dustin Sallings (Inactive) added a comment -

            (In reply to comment #3)
            > Btw, the memory byte used also behaves likes item count. going down only if you
            > try to get these items (and fail).

            That is correct. There's no way to know what's there or not other than by looking, and looking is expensive.

            Show
            dustin@sallings.org Dustin Sallings (Inactive) added a comment - (In reply to comment #3) > Btw, the memory byte used also behaves likes item count. going down only if you > try to get these items (and fail). That is correct. There's no way to know what's there or not other than by looking, and looking is expensive.
            Hide
            raju Raju Suravarjjala added a comment -

            Bulk closing all invalid bugs that are duplicate, user error, invalid. Please feel free to reopen them if you feel otherwise

            Show
            raju Raju Suravarjjala added a comment - Bulk closing all invalid bugs that are duplicate, user error, invalid. Please feel free to reopen them if you feel otherwise

              People

              Assignee:
              dustin@sallings.org Dustin Sallings (Inactive)
              Reporter:
              perry Perry Krug
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Gerrit Reviews

                  There are no open Gerrit changes

                    PagerDuty