Uploaded image for project: 'Couchbase Go SDK'
  1. Couchbase Go SDK
  2. GOCBC-1089

Add a config option to allow 'ErrOverload' to be a blocking operation

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: library
    • Labels:
      None
    • Story Points:
      1

      Description

      What's the issue?
      When queuing an operation with 'gocbcore' it may fail because the operation queue is currently full. Currently this error is returned to the user, they must wait/sleep and then attempt to queue the operation again. This isn't ideal because it introduces the possibility that the queuing thread is sleeping when there's actually space in the queue.

      What's the fix?
      It would be slightly more efficient/easier for the caller, if we could have 'ErrOverload' be a blocking operation i.e. it will wait for the queue to have enough room (likely using some form of condition variable with broadcast/signal) to allow a new item to immediately be queued.

      Obviously this would need to be done via a config option which is defaulted to off to avoid breaking backwards compatibility.

        Attachments

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

          Activity

          Hide
          charles.dixon Charles Dixon added a comment -

          We're not hugely keen on the idea of being able to block our blocking API for this. As well as that it will introduce races unless we introduce another bounded queue (which will just be pushing the ErrOverload issue to another place) - the scenario where multiple goroutines are writing to gocbcore and hitting ErrOverload, we would have no way of prioritising the older requests.

          I will keep thinking on a way to handle this from a user side but closing out this ticket.

          Show
          charles.dixon Charles Dixon added a comment - We're not hugely keen on the idea of being able to block our blocking API for this. As well as that it will introduce races unless we introduce another bounded queue (which will just be pushing the ErrOverload issue to another place) - the scenario where multiple goroutines are writing to gocbcore and hitting ErrOverload, we would have no way of prioritising the older requests. I will keep thinking on a way to handle this from a user side but closing out this ticket.

            People

            Assignee:
            james.lee James Lee
            Reporter:
            james.lee James Lee
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes

                  PagerDuty