federated query infrastructure

[VladimirAlexiev]

4 of the Jena Federated tests have failed. http://172.17.0.2/sparql reports Error 503 Backend fetch failed. It accesses two other endpoints: http://172.17.0.4/sparql and http://172.17.0.4/sparql, and one of them has failed.

IT seems to me that one of them has failed. (I tried now, none of them responds, but maybe they are behind a firewall or something)

[VladimirAlexiev]

Also, you report error for syntax-service-01.rq and I'm not sure why. This is a positive syntax test, and the syntax is correct:

BASE <https://bordercloud.github.io/rdf-tests/sparql11/data-sparql11/syntax-fed/>
SELECT * { SERVICE <g> { ?s ?p ?o } }

Jena goes off to query https://bordercloud.github.io/rdf-tests/sparql11/data-sparql11/syntax-fed/g which fails, and correctly returns Error 503 Backend fetch failed.

I don't know whether you have a special implementation for "syntax-only" tests. In this case you'd need to ask the service "is the syntax of the query correct" and there's no standard way to do this...

[BorderCloud]

172.17.0.X are intern IP of dockers. In my test, I create 4 dockers in same time. One service to test and 3 other for the services necessary in the federated queries.

503... probably an error in the transaction between Fuseki and Virtuoso.
I need to export the logs of docker in the report of the error.

[VladimirAlexiev]

So do you use Virtuoso as the "backend" endpoint for each Fed test? Another option would be to use "self" (i.e. Fuseki when testing Fuseki; Virtuoso when testing Virtuoso...) Considerations

• (-) by always using Virtuoso as the "backend", you give it an "unfair advantage"
• (+) cross-testing between repos will test their compatibility
• (-) cross-testing is a lot more complex to organize
• (+) testing against "self" means a repo won't be penalized for mistakes in a different "backend" repo

[BorderCloud]

I think. There are 2 options.

Option 1 : I generate automatically the tests of federated query with all the dockers of service SPARQL. And so I can test all the possibility...

Option 2 : I (or anybody) can develop a real mock of SPARQL service. With it we can test correctly the protocol with federated queries...

For the moment, I use Virtuoso... I can change...for example with Jena I can deploy one Virtuoso, one StarDog and Blazegraph in the other services. With Virtuoso : Jena, Blazegraph and StarDog... etc.

[VladimirAlexiev]

Option 2 is the way because relying on other people to keep backend fed services running will lead to disappointment. You describe the "cross-testing" scenario. It's more powerful since will also test compatibility across repositories. However, it's significantly more complex to maintain, and to "attribute" a failure (is it in the SUT frontend repo, or the backend fed repo?)