Reduce scan latency for stale=false after bucket flush
Description
Components
Fix versions
Labels
Environment
Link to Log File, atop/blg, CBCollectInfo, Core dump
Release Notes Description
Attachments
- 16 May 2016, 11:46 AM
- 16 May 2016, 11:46 AM
- 28 Apr 2016, 04:47 AM
- 27 Apr 2016, 02:42 PM
- 27 Apr 2016, 12:00 PM
relates to
Activity

Raju Suravarjjala April 27, 2017 at 5:22 PM
Bulk closing invalid, won't-fix, duplicate bugs. Please feel free to reopen

Prathibha Bisarahalli April 25, 2017 at 8:40 AM
The issue is not reproducible in Spock build. Trying running repro script in one node setup as well as a cluster with 3 nodes with all services enabled.
The scan vector computation moved to server side as part of commit https://github.com/couchbase/indexing/commit/bf687244dd312bf022e5a6937ab99716506adb64 and hence the timeout issue is mitigated after bucket flush.

Simon Baslé May 17, 2016 at 9:11 AM
that indeed looks like the issue john, keshav and I were seeing back then!

p May 16, 2016 at 4:30 PM
Modified the script to do another RP (request plus query) query after the first one.
9. RP-query-1 result:
{
"elapsedTime": "2m0.104445894s",
"executionTime": "2m0.104399094s",
"resultCount": 1,
"resultSize": 31
}
10. RP-query-2 result:
{
"elapsedTime": "6.586935ms",
"executionTime": "6.541229ms",
"resultCount": 1,
"resultSize": 31
}
the first RP query timesout but the second one succeeds.

p May 16, 2016 at 11:43 AMEdited
With 4.1.0 Build 5008 I can reproduce this issue with the attached script(n1ql-query-index-hangs.zip).
using Ubuntu14.04, 3 node cluster and all services enabled on all nodes.
On one of the nodes I am observing this,
2016-05-16T11:35:08.82+00:00 [Info] SCAN##3 REQUEST defnId:16030325685263847945, index:default/iQA, type:scan, span:range (["Hello","World!"],["Hello","World!"] incl:both), limit:9223372036854775807, consistency:session_consistency, requestId:68cba256-87c4-469a-a1a3-a422097c7335
2016-05-16T11:35:08.82+00:00 [Info] SCAN##3 RESPONSE status:(error = Index scan timed out), requestId: 68cba256-87c4-469a-a1a3-a422097c7335
I am also attaching the indexer.log.
Details
Details
Assignee

Reporter

Priority
Instabug
PagerDuty
PagerDuty Incident
PagerDuty

Sentry
Linked Issues
Sentry
Zendesk Support
Linked Tickets
Zendesk Support

After bucket flush, the first stale=false scan will take 2 minute (timeout) before gsiClient to retry the operation. For developer experience and usability, this should be improved.