Uploaded image for project: 'Couchbase .NET client library'
  1. Couchbase .NET client library
  2. NCBC-1433

investigate prepared statement client cache racyness

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • 2.4.5
    • 2.4.7
    • library
    • None

    Description

      From a forum discussion, a user reports that if they fire off a lot of async requests at once they end up preparing a large number of times. This indicates that there might be a synchronization problem during prepare if we're preparing multiple times. If the statement is the same it should prepare once and cache.

      Since the actual prepare logic is expensive, it might make sense to index into whatever data structure we're using in the .NET client cache with a state that it's preparing, then backoff and retry from multiple callers.

      Attachments

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

        Activity

          jmorris Jeff Morris added a comment -

          Yes, there is nothing stopping requests on multiple threads from doing the prepare. I suspect if we block on a large amount of callers, waiting for the prepare to complete, then you'll see some timeouts. That is probably the best option here.

          jmorris Jeff Morris added a comment - Yes, there is nothing stopping requests on multiple threads from doing the prepare. I suspect if we block on a large amount of callers, waiting for the prepare to complete, then you'll see some timeouts. That is probably the best option here.

          Yeah, I agree. We would introduce latency on checking and waiting for prepared statements to be cached. We could maybe a option to wait, but I don't think it would be used much.

          What the forum poster did, to prepare the statements ahead of the load test, is the best option. If an application has known statements, it could prepare them as part of start up to ensure they are ready for normal processing.

          mike.goldsmith Michael Goldsmith added a comment - Yeah, I agree. We would introduce latency on checking and waiting for prepared statements to be cached. We could maybe a option to wait, but I don't think it would be used much. What the forum poster did, to prepare the statements ahead of the load test, is the best option. If an application has known statements, it could prepare them as part of start up to ensure they are ready for normal processing.

          After further discussion with Jeff Morris and Matt Ingenthron we think that we should not introduce a blocking process to prevent multiple concurrent prepare requests as will introduce additional latency. We have agreed we will release note this scenario with a suggestion to prepare known expensive queries during application start where possible.

          mike.goldsmith Michael Goldsmith added a comment - After further discussion with Jeff Morris and Matt Ingenthron we think that we should not introduce a blocking process to prevent multiple concurrent prepare requests as will introduce additional latency. We have agreed we will release note this scenario with a suggestion to prepare known expensive queries during application start where possible.

          People

            jmorris Jeff Morris
            ingenthr Matt Ingenthron
            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