Reporting issues
A description on information to include when reporting an issue (JIRA).
When reporting issues to Couchbase, add the following information to JIRA issues:
- Provide a description of your environment (for example, package installation, cluster_run, build number, operating system, and so on).
- Show all the steps necessary to reproduce the issue (if applicable).
- Show the full content of all the design documents.
- Describe how your documents are structured (for example, if they are all same structure or if they have different structures).
- If you generated the data with a tool, identify the tool name and all the parameters given to it (full command line).
Show the queries you were performing (include all query parameters and the full URL). For example, if you are using curl, use the verbose option (-v) and show the full output.
The following request uses curl with the -v option with test as the bucket, dev_zlat as the design document, and Python (installed separately) as the tool used to format the output.
curl -v http://10.5.2.54:8092/test/_design/dev_zlat | python -m json.tool
* About to connect() to 10.5.2.54 port 8092 (#0)
* Trying 10.5.2.54... % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected
* Connected to 10.5.2.54 (10.5.2.54) port 8092 (#0)
GET /test/_design/dev_zlat HTTP/1.1
User-Agent: curl/7.21.4 (x86_64-unknown-linux-gnu) libcurl/7.21.4 OpenSSL/0.9.8b zlib/1.2.3
Host: 10.5.2.54:8092
Accept: */*
HTTP/1.1 200 OK
X-Couchbase-Meta: {"id":"_design/dev_zlat","rev":"1-08738b26","type":"json"}
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Mon, 24 Nov 2014 21:17:13 GMT
Content-Type: application/json
Content-Length: 159
Cache-Control: must-revalidate
{ [data not shown]
100 159 100 159 0 0 36780 0 --:--:-- --:--:-- --:--:-- 79500* Connection #0 to host 10.5.2.54 left intact
* Closing connection #0
{
"views": {
"byloc": {
"map": "function (doc, meta) {\n
if (meta.type == \"json\") {\n emit(doc.city, doc.sales);\n }
else {\n emit([\"blob\"]);\n }\n}"
}
}
}
- Repeat the query with different values for the stale parameter and show the output
- Attach logs from all nodes in the cluster
- Try all view related operations, including creating, updating, and deleting design documents from the command line. The goal is to isolate UI problems from the view engine.
- If you suspect the indexer is stuck or blocked, use curl against the
_active_tasks API to isolate UI issues from view-engine issues. For example:
curl -s http://10.5.2.54:8092/_active_tasks [ { "limit": 16, "pid": "<0.1006.0>", "running": 0, "started_on": 1407799619, "type": "couch_main_index_barrier", "updated_on": 1410294790, "waiting": 0 }, { "limit": 2, "pid": "<0.1007.0>", "running": 0, "started_on": 1407799619, "type": "couch_replica_index_barrier", "updated_on": 1407799619, "waiting": 0 }, { "limit": 4, "pid": "<0.1008.0>", "running": 0, "started_on": 1407799619, "type": "couch_spatial_index_barrier", "updated_on": 1407799619, "waiting": 0 } ]
Note: The started_on and update_on fields are
UNIX timestamps. There are tools (even online) and programming language APIs (Perl, Python,
etc) to convert them into human readable form, including date and time. The
_active_tasks API contains information on the specific nodes, so query
_active_tasks on every node in the cluster to verify whether progress
is stuck.