Community

MarkLogic 10 and Data Hub 5.0

Latest MarkLogic releases provide a smarter, simpler, and more secure way to integrate data.

Read Blog →

Company

Stay On Top Of Everything MarkLogic

Be the first to know! News, product information, and events delivered straight to your inbox.

Sign Me Up →

 
Knowledgebase:
Killing a Long running Query and Request Time Limits
30 June 2015 02:36 PM

Summary

This article explains how to kill Long Running Query and related timeout configurations.

Problem Scenario

At some point, we've all run into an inefficient long running query. What should we do if we don't want to wait for the query to complete? If we cancel the browser request, that would end the connection, but it wouldn't end the program invocation (called a "request") on the MarkLogic Server side. On the server side, that program invocation would continue to run until the execution is complete.

Most of the time, this isn't really an issue. The server, of course, is multi-threaded, handling many concurrent transactions. We can just cancel the browser request, move on, and let the query finish when it finishes. However, sometimes it becomes necessary to free up server resources by killing the query and starting over. To do this, we need access to the Admin interface. 

Sample Long running Query 

Example only, please don't try this on any production machines!

for $x in 1 to 1000000
return collection()[1 + xdmp:random(1000)]
 
This query is asking for 1,000,000 random documents, and will take a long time to execute. How can we cancel this query?

How to Cancel/Kill the Query

Go to the Administrative interface (at http://localhost:8001/ if you're running MarkLogic locally). At the top of the screen, you'll see a tab labeled "Status." Click that:

screenshot1.jpg

This will take you to the "System Status" screen. This page reveals status information about hosts, databases, forests, and app servers. The App Server section is what we're concerned with. Scanning down the "Queries" column, we see that the "Admin" server is processing a query (namely, the one that generated the page we see). Everything looks okay so far. But just below that, we see that the "App-Services" server is just over 3 minutes into processing a query. That's our slow one. Query Console runs on the "App-Services" app server, which explains why we see it there. Go ahead and click the "App-Services" link:

screenshot2.jpg

This takes us to the "App-Services" status page. So far, there's still no "cancel" button. One more click will reveal it ("show more"):

screenshot3.jpg

We can now see an individual entry for the currently running query. Here we see it's called "eval.xqy"; that's the query module that Query Console invokes when you submit a query. If you were running your own query module (instead of using Query Console), then you would see its name here instead. To cancel the query, click the "[cancel]" link:

screenshot4.jpg

One more click (on the confirmation page).

screenshot5.jpg

This takes us back to the status page, where we see MarkLogic Server is in the process of canceling our query:

screenshot6.jpg

Above page will continue to say "cancelling..." even though query is already killed and no longer exist till we refresh the page.

A quick refresh of the above page shows that the query is no longer present.

screenshot7.jpg

 

What happens if you forget to cancel a query?

MarkLogic will continue to execute the query until a time limit is reached, at which point the Server will cancel the query for you. For example, here's what Query Console eventually returns back if we don't bother to cancel the query:

screenshot8.jpg

How long is this time limit?

This depends on your server configuration. We can actually set the timeout in the query itself, using the xdmp:set-request-time-limit() function, but even that will be limited by your server's "max time limit."

For example, on the "Configure" tab of my "App-Services" app server, you can see that the "default time limit" is set to 10 minutes (600 seconds), and the longest any query can allow itself to run (by setting its own request time limit) is one hour (3600 seconds):

screenshot9.jpg

 

(1 vote(s))
Helpful
Not helpful

Comments (0)