Last modified: 2014-08-01 18:08:40 UTC
I am running a webservice on instance wikidata-wdq-mm port 80. This works reasonably well, but large results sets cause a "502 Bad Gateway" error. Example: http://wdq.wmflabs.org/api?q=claim[31]&props=31 The thing is, if I run the exact same query on the exact same data on my home machine, it works fine (both in browser and curl). It does take a while (~25sec at home, ~40? on Labs) to generate the result set, but the http header should be send earlier to prevent connection drop. The webservice uses the "compiled-in" mongoose web server, so the usual Apache 502 fixes from the web don't apply. Since the error also occurs when doing curl from Labs shell, I assume it's something on Labs, rather than outside. Any idea how to fix this?
From the outside, "wget http://wdq.wmflabs.org/" retrieves something immediately, while "wget 'http://wdq.wmflabs.org/api?q=claim[31]&props=31'" returns a 502, so the webserver on the instance seems to be accessible and responding. On tools-login, "wget 'http://wikidata-wdq-mm/api?q=claim[31]&props=31'" (bypassing the nginx proxy) times out after about a minute. Another test with "curl -gi 'http://wikidata-wdq-mm/api?q=claim[31]&props=31'" doesn't seem to indicate that the http header is indeed sent earlier: | scfc@tools-login:~$ curl -gi 'http://wikidata-wdq-mm/api?q=claim[31]&props=31' | curl: (52) Empty reply from server | scfc@tools-login:~$ "wget http://wikidata-wdq-mm/" retrieves something immediately, again. So to me the problem seems to lie with the script taking too long.
Changed timeout in library code, works now.
