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.