Query Workbench 60s timeout - how to extend?

SQL++
1

Hi all,

I would prefer to use the query workbench sometimes as I am not always using the same laptop.
On occasion I need to run a query longer than 60 seconds.

Is there a config file for the query workbench, or some other server-side setting where I can set the timeout to 300 seconds?

thanks

Si

2

I’ve referred this question to one of our engineers who works on the query workbench. You should get an answer shortly.

3

Which version of Couchbase are you using?

In 4.5/4.6, the timeout should be set for 300 seconds (that’s what the code indicates). Are you seeing something different?

In 5.0, there is a settings dialog that lets you set any value.

4

Hi Eben,

Thanks fir investigating.
This is on 4.5.1 enterprise. The timeout error message says something like “workbench limited to 300 seconds” but it is timing out after 60.

We have gold support so if this is unexpected behaviour should i raise a ticket?

Si

5

That behavior is not expected. I found instances of 4.5.1 and 4.6.1, and both of them issue the following message after 300 seconds:

{
  "status": "Gateway Timeout",
  "status_detail": "The query workbench only supports queries running for 300 seconds. Use cbq from the command-line for longer running queries. Certain DML queries, such as index creation, will continue in the background despite the user interface timeout."
}

Is that what you are seeing after 60 seconds? Or something else?

This certainly could be worth raising a ticket if we don’t find a work-around for you.

6

Yes that is exactly the error, it even says 300 seconds but times out after 60.

Interestingly I have just confirmed that this only occurs on out production cluster - dev and test are fine (300 seconds), we just never noticed as they have much less data.

Something that may be relevant - when we first installed, the Query tab was not showing at all and after a call with professional services we came to the conclusion it was just a UI glitch and not worth re-installing. If we navigate directly to https:///ui/index.html#/query/workbench it works fine and the query tab magically appears.

Si

7

Actually the json response isn’t exactly like that, it includes some HTML:

{
“status”: “\r\n504 Gateway Time-out\r\n<body bgcolor=“white”>\r\n

504 Gateway Time-out

\r\n
nginx/1.13.1\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n”,
“status_detail”: “The query workbench only supports queries running for 300 seconds. Use cbq from the command-line for longer running queries. Certain DML queries, such as index creation, will continue in the background despite the user interface timeout.”
}`

edit. - the html is being rendered

8

Curiouser and curiouser!

Looking at the code, it appears that in 4.5.1 the query tab was hidden unless the user logged in as the cluster administrator. In later versions of 4.6 we have removed this restriction - we found it unnecessary because users without permissions to query the data will get an appropriate error when issuing the query.

Are you logged in to the production cluster as a user other than the cluster Administrator? I can’t see why that would affect query timeouts, but it’s possible there’s some kind of bug for lower privileged users.

9

Yes I always log in as Administrator. In fact it is the only account we’ve got setup

10

Just experimenting a bit.

http://server-name/ui/#/overview does not show the query tab, but
http://server-name/ui/index.html#/overview does!

11

Ah, yes. That behavior with the URLs is a known issue, due to the changeover in UI code from 4.0 to 4.5. It was fixed in a later release.

Back to your query timeout issue, can you open your browser’s javascript console and see if any errors are appearing there? If not, you probably should open a ticket and upload all the log files so we can figure out what’s going on.

12

Chrome developer console reports the following:

debug.js Failed to load resource: the server responded with a status of 404 (Object Not Found)
/pools/default/tasks Failed to load resource: the server responded with a status of 401 (Unauthorized)
/pools Failed to load resource: the server responded with a status of 401 (Unauthorized)

13

Those console messages you reported are normal output from when you first connect, and need to log in.

There may be clues to the problem in the logs, so I’d suggest opening a ticket, noting what time(s) that you have seen the issue, and uploading your logs. That way we can see if there is some server issue at those times causing the premature timeout.