Uploaded image for project: 'Couchbase node.js Client Library'
  1. Couchbase node.js Client Library
  2. JSCBC-294

High count of the following errors when performing N1QL queries

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.1.5
    • 2.1.6
    • library
    • None
    • OS: CentOS 7
      Edition: Couchbase 4.0 Community
      SDK: couchnode v2.1.5

    Description

      High count of the following errors when performing N1QL queries:
      An unknown error occured

      An unknown N1QL error occured

      We have implemented a temporary retry loop, but the frequency at which these occur is a bit too high and results in clint side-timeouts as well (>60/90 seconds)

      Attachments

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

        Activity

          brett19 Brett Lawson added a comment -

          Hey Almir,

          Could you explain what kind of queries you are running, how often you are running them and the approximate amount of data returned by those queries? The whole error you should have been receiving should be something like: "An unknown N1QL error occured. This is usually related to an out-of-memory condition.".

          Cheers, Brett

          brett19 Brett Lawson added a comment - Hey Almir, Could you explain what kind of queries you are running, how often you are running them and the approximate amount of data returned by those queries? The whole error you should have been receiving should be something like: "An unknown N1QL error occured. This is usually related to an out-of-memory condition.". Cheers, Brett
          AlmirKadric Almir Kadric added a comment -

          Hi Brett,

          Below is probably the heaviest SQL query we run in the application. Also this is run whenever a user lists all the popular performances in the application. As the LIMIT suggests, we never return more than a 1000 entries but because of the ORDER I'm assuming all entries are loaded then ordered then reduced. Also we do not use a global index. All relevant pieces are individually indexed.

          SELECT
              DISTINCT p.pid
          FROM `performance` p
          JOIN `performance` ps ON KEYS "performanceStats/pid:" || p.pid
          JOIN `user` u ON KEYS "user/userId:" || p.userId
          WHERE
              meta(p).id LIKE "performance/%" AND
              p.pid IS NOT MISSING AND
              p.isEnabled = TRUE AND
              p.isDeleted = FALSE AND
              p.expiredAt > 1460967043481 AND
              p.userId = "8f526241-f777-400d-a152-bd75f5d1d248" AND
              (
                  p.userId = "8f526241-f777-400d-a152-bd75f5d1d248" OR
                  p.shareTarget = "public" OR
                  (
                      p.shareTarget = "userIds" AND
                      "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN p.shareUserIds
                  ) OR
                  (
                      p.shareTarget = "friend" AND
                      "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN (SELECT friendIds FROM `user` USE KEYS "friend/userId:" || p.userId)
                  ) OR
                  (
                      p.shareTarget = "follower" AND
                      "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN (SELECT followerIds FROM `user` USE KEYS "follow/userId:" || p.userId)
                  )
              )
          ORDER BY p.createdAt DESC
          LIMIT 1000
          

          AlmirKadric Almir Kadric added a comment - Hi Brett, Below is probably the heaviest SQL query we run in the application. Also this is run whenever a user lists all the popular performances in the application. As the LIMIT suggests, we never return more than a 1000 entries but because of the ORDER I'm assuming all entries are loaded then ordered then reduced. Also we do not use a global index. All relevant pieces are individually indexed. SELECT DISTINCT p.pid FROM `performance` p JOIN `performance` ps ON KEYS "performanceStats/pid:" || p.pid JOIN `user` u ON KEYS "user/userId:" || p.userId WHERE meta(p).id LIKE "performance/%" AND p.pid IS NOT MISSING AND p.isEnabled = TRUE AND p.isDeleted = FALSE AND p.expiredAt > 1460967043481 AND p.userId = "8f526241-f777-400d-a152-bd75f5d1d248" AND ( p.userId = "8f526241-f777-400d-a152-bd75f5d1d248" OR p.shareTarget = "public" OR ( p.shareTarget = "userIds" AND "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN p.shareUserIds ) OR ( p.shareTarget = "friend" AND "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN (SELECT friendIds FROM `user` USE KEYS "friend/userId:" || p.userId) ) OR ( p.shareTarget = "follower" AND "8f526241-f777-400d-a152-bd75f5d1d248" WITHIN (SELECT followerIds FROM `user` USE KEYS "follow/userId:" || p.userId) ) ) ORDER BY p.createdAt DESC LIMIT 1000

          People

            brett19 Brett Lawson
            AlmirKadric Almir Kadric
            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