re: status code. This is an interesting problem. The http spec does not 
have a good answer for this right now as you point out below. Internally 
(we don't use fuseki), our app server returns 503 when a query times out. 
It is not perfect, but it indicates the temporary nature of the problem, 
i.e. if you add resources to the machine or change the timeout value, you 
may get  200 again. Ideally, there is a 4xx class answer since a timeout 
is not really a server error (unless you consider a lack of CPU/memory a 
server problem :-) ). I looked at [5] below and 403 does not seem entirely 
wrong but we didn't choose it (we use 403 for a number of other things and 
it would require our clients to further disambiguate the cause for 403), 
although arguably that can also be said for 503. The main difference 
though is that 503 suggests that retrying could alleviate the problem and 
that is technically true because a query (in our product) may timeout 
because the server is overloaded with requests.

Simon




From:
Alexander Dutton <[email protected]>
To:
"[email protected]" <[email protected]>
Date:
11/09/2011 10:50 AM
Subject:
QueryCancelledException not being caught in Fuseki




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm playing with the --timeout argument to Fuseki (checked out from
trunk a couple of days ago).

When a query times out the client currently receives the following,
which doesn't explain much:

> Error 500: Server Error

This is the result of a QueryCancelledException being caught at line
107 of SPARQL_ServletBase, which has the comment "This should not happen"

It'd be good if this were explicitly caught and a more user-friendly
error message provided. I don't know what HTTP status code should be
provided[1]. The spec does say 500, but that upsets me (and Hugh
Glaser)[2].

Shall I create an issue in JIRA and put together a patch?

Yours,

Alex

[1] I've asked[2] the HTTP WG whether they'd consider the inclusion of
a "Request Too Onerous" status code in the new status code draft[3].
[2] There's been previous discussion of this on public-lod[5].
[3] http://lists.w3.org/Archives/Public/ietf-http-wg/2011OctDec/0188.html
[4] http://tools.ietf.org/html/draft-nottingham-http-new-status-03
[5] http://lists.w3.org/Archives/Public/public-lod/2011Apr/0259.html ff.

- -- 
Alexander Dutton
Metamorphoses Project Developer, Claros
Oxford University Computing Services, ℡ 01865 (6)13483
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk66oKMACgkQS0pRIabRbjAZ1QCfSBhh8aPVwD3FxM9y1Obxi3f1
zN8AnjDu68k++p5mbi6O9AxZoSGRuzb6
=kJIA
-----END PGP SIGNATURE-----



Reply via email to