How do I kill a query?

by Evan Lenz

Have you ever run some code in Query Console only to realize that your query was going to take way too long to finish? Perhaps you made a mistake and didn't want to wait for the query to complete. If you canceled the browser request, that would end the connection, but it wouldn't end the program invocation (called a "request") on the MarkLogic side. It 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. Just cancel the browser request, move on, and let the query finish when it finishes. But sometimes it becomes necessary to free up server resources by killing the query and starting over. To do this, you need access to the Admin interface. I'm going to walk you through this. It's simple once you know where to look.

First, I'll run a pathological query. Don't try this at home (at least not on any production machines)!

for $x in 1 to 1000000
return collection()[1 + xdmp:random(1000)]

This is asking for 1,000,000 random documents—in other words, trouble. Needless to say, this will take a long time to execute, leaving us plenty of time to figure out how to cancel the query. One brute-force way to stop executing it would be to restart MarkLogic Server (and that's probably what I did before I knew better.) But that's unnecessary.

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:

Machine generated alternative text: Summary Databases (17’) -- Index. query. and App Servers (19) -- Enable Groups (1) --Allow hosts to share a content processing con figuration connectns from client software common con figuratien

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:

Machine generated alternative text: Average Request Oldest Expanded Tree Cache Host Threads Queues Updates Time Rato Request Hits Misses Ratio 123-http-server [httpj O O n/a O n/a O O nia App Server 1 1 ovar ienzs macbook pro.iocai ev an Ienzs macbook proiocai O O n/a O n/a O 9000-Docs [xdbcj Mmin [httpJ O nia ienzs macbook pro. ocal ovar- 7 1 0 14.7ma 4.43 14.7 ms 2,177 385 85% Carrot [httpj App-Services ovan- 2 1 0 00:03:02 0 00:03:02 156.844.462 15,210 100% [httpj — ienzs macbook pro.iocai ovan lenza macbook pro.Iocai I O O n/a O n/a O O n/a

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"):

Machine generated alternative text: HTTP Server: App-Services App Server Status • Create XDBC I Help Ewmoraj appserver status - A detailed view of this appservers activity. App Server App-Services [H1TPI Database App-Services Host Threads Requests Updates Time evar- 2 leras macbook pro local Average Request Oldest Expanded Tree Cache Rate Request Hits MIsses Ratio 00:03:19 263,377,407 15,215 100% • Summary • Configure Status ‘ Create HTTP ‘[Cre 0 00:03:19 0 2 1 0 00:03:19 0 263,377,407 15,215 100%

And voila! We 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:

Machine generated alternative text: App Server Status r Summary J Configure Status J Create HTTP Jcreate WebDAVJ Create XDBC J Help HTTP Server: App-Services show less appserver status A detailed view of this appserver’s activity. App Server App-Servces [HTP] Database AppServices Average Request Oldest Expanded Tree Cache Host Threads Requests Updates Time Rate Request Hits Misses Ratio evan-ierzs- 2 1 0 00:04:22 0 00:04:22 274,408,780 15,215 100% macbook pro.locai 2 1 0 00:04:22 0 274,408,780 15,215 100% Average Oldest Expanded Tree Cache Query # Time Time Hits Misses Ratio Iqconsoi&endpoirts/evai.xqy 1 00:04:22 00:04:22 1 1 50% Total 1 00:04:22 00:04:22 1 1 50% Expanded Tree Cacho Time Host Query User Client iP Time Hits Misses Ratio Limit ovar- /qconsoielerdpoirts/evai.xqy adrnin 127.0.0.1 00:04:22 1 ¶ 50% 600 [stack) [carceij macbook proJetai Total 1 1 50%

One more click (on the confirmation page), and we're home free:

Machine generated alternative text: Are you sure you want to cancel the request: lqconsolelendpointsieval.xqy 0k cancel

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

Machine generated alternative text: Expanded Tree Cache Time Host Query User Client IP Time Hits Misses Ratio Limit evar- /qconsoielendpoirtsðevai.xqy adrnir 127.0.0.1 0007:10 1 1 50% 600 [stackj  macbook pro.Iocai Total 1 1 50%

A quick refresh of the page shows that the query is as good as gone:

Machine generated alternative text: Expanded Tree Cache Host Query User Client IP Time Hits Misses Ratio Time Limit None Total nia nia nia

What happens if you forget to cancel a query? Will MarkLogic keep on trucking forever, doing what you told it to do? No, this depends on your configuration, but your query will reach a time limit, at which point the Server will cancel the query for you. For example, here's what Query Console eventually returns back if I don't bother canceling the query:

Machine generated alternative text: ¡ [1.0-ml] XDMP-EXTIME: fn:collectionO[1 + xdmp:random(1000)] -- Time limit exceeded Stack Trace At line 4 column 23: : 6995 3. for $x in 1 to iøeeøøø 4. return co11ection[1 xdmp:randoi(1eøø)] 5.

How long is this time limit? Well, that depends on your server configuration. You 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 highest any query can allow itself to go (by setting its own request time limit) is one hour (3600 seconds):

Machine generated alternative text: maxtime limit The upper bound for a requesVs time limit, in seconds, defaulttimelimlt The default time limit for a request, in seconds.

If you're thinking to yourself, "Yes! Now I can run those really slow queries without them getting automatically killed!" I would suggest to you that there is a better way. If you have queries that run that long, then run, do not walk, to the Developer mailing list (which you can easily subscribe to by signing up as a Community member), or post your question on Stack Overflow, tagging it with "marklogic". I think you'll find that your time doing either of these is well spent (it might even make your day!).

Comments