Page MenuHomePhabricator

Federated SPARQL queries https://data.pdok.nl/sparql failing with error 500
Closed, ResolvedPublic

Description

This weekend we have been trying SPARQL federation queries. If we do https://data.pdok.nl directly ( http://tinyurl.com/y9hl3vd5 ) it fails, if we federate it through another SPARQL server it works ( http://tinyurl.com/y9bc3clv ). It also works from the SPARQL test instance on wmflabs and a curl from the production Blazegraph server.

Event Timeline

Restricted Application added a project: Discovery. · View Herald TranscriptMay 20 2018, 1:36 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

The end of the stack trace, for future reference:

Caused by: com.bigdata.rdf.sail.webapp.client.HttpException: Status Code=500, Status Line=Internal Server Error, Response=<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
 root@localhost and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>

	at com.bigdata.rdf.sail.webapp.client.RemoteRepositoryBase.checkResponseCode(RemoteRepositoryBase.java:102)
	at com.bigdata.rdf.sail.webapp.client.RemoteRepositoryManager.tupleResults(RemoteRepositoryManager.java:2178)
	at com.bigdata.rdf.sparql.ast.service.RemoteServiceCallImpl.call(RemoteServiceCallImpl.java:153)
	at com.bigdata.rdf.sparql.ast.service.RemoteServiceCallImpl.call(RemoteServiceCallImpl.java:51)
	at com.bigdata.bop.controller.ServiceCallJoin$ChunkTask$ServiceCallTask.doNonBigdataSesameServiceCall(ServiceCallJoin.java:839)
	at com.bigdata.bop.controller.ServiceCallJoin$ChunkTask$ServiceCallTask.doRemoteServiceCall(ServiceCallJoin.java:803)
	at com.bigdata.bop.controller.ServiceCallJoin$ChunkTask$ServiceCallTask.doServiceCall(ServiceCallJoin.java:717)
	... 6 more

Noticed that as well.

Maybe it has something to do with the list of prefixes that is being sent.

When I send data from my local laptop, everything works fine. With curl from production host I get 404. I suspect there's something to do with proxies maybe.

Smalyshev triaged this task as Normal priority.Jun 21 2018, 11:27 PM
Vvjjkkii renamed this task from Federated SPARQL queries https://data.pdok.nl/sparql failing with error 500 to 0kcaaaaaaa.Jul 1 2018, 1:08 AM
Vvjjkkii raised the priority of this task from Normal to High.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
CommunityTechBot lowered the priority of this task from High to Normal.
CommunityTechBot renamed this task from 0kcaaaaaaa to Federated SPARQL queries https://data.pdok.nl/sparql failing with error 500.
CommunityTechBot added a subscriber: Aklapper.
Smalyshev moved this task from Backlog to Next on the User-Smalyshev board.Oct 14 2018, 6:49 PM

If this gets stuck on debugging on our side, I could probably ask around for contact details for the people running https://data.pdok.nl/sparql . On https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Federation_report several other endpoints are also failing. Solving the pdok.nl problem might fix some of the others too.

Some of the endpoints there are dead (I removed them from Wiki, but I keep it in the whitelist in case they'd go back to life). Others fail for unknown reasons, I'll investigate it. Some are listed as failed - e.g. https://data.epo.org/linked-data/query - but work fine for me.

Husky removed a subscriber: Husky.Oct 14 2018, 8:10 PM

Tried it again with Curl and it seems to work OK. I suspect this is the same ALPN issue as in T202785: Federation request to https://ld.stadt-zuerich.ch/query fails.

Tried it again with Curl and it seems to work OK. I suspect this is the same ALPN issue as in T202785: Federation request to https://ld.stadt-zuerich.ch/query fails.

Is that something we need to fix on our side or something that can be fixed on the data.pdok.nl side?

We probably can't fix it until we migrate to Jetty that supports ALPN. On the other side, it may be possible to fix it if the server would handle non-APLN clients properly but I am not sure how to configure and test it, unfortunately... I don't have too much knowledge into inner workings of ALPN and I have no idea which software data.pdok.nl runs.

Smalyshev closed this task as Resolved.Nov 14 2018, 7:50 PM
Smalyshev claimed this task.

This seems to work now, looks like upgrade to jetty 9.4 fixed it.