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.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T197530 [tracking] federation query issues on Wikidata Query Server | |||
| Resolved | Smalyshev | T195203 Federated SPARQL queries https://data.pdok.nl/sparql failing with error 500 |
Event Timeline
Comment Actions
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
Comment Actions
Noticed that as well.
Maybe it has something to do with the list of prefixes that is being sent.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
Is that something we need to fix on our side or something that can be fixed on the data.pdok.nl side?
Comment Actions
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.