Internal server error with reasoning queries and slow reasoning issue

Support
1

Hi all,
Just wondering if Stardog does not support reasoning queries with rdfs:label? It simply showed me Internal Server Error. I checked the log where I found it gave me following error while querying rdfs:label:

ERROR 2017-03-31 12:31:40,129 [StardogServer.WorkerGroup-0] com.complexible.stardog.protocols.http.server.HttpMessageEncoder:write(171): There was an error writing the HTTP response org.openrdf.query.QueryEvaluationException: java.util.NoSuchElementException at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.hasNext(IteratorAsTupleQueryResult.java:81) ~[stardog-utils-rdf-4.2.3.jar:?] at com.complexible.stardog.protocols.server.ConnectionFinishQueryResult.hasNext(ConnectionFinishQueryResult.java:75) ~[stardog-protocols-spec-server-4.2.3.jar:?] at org.openrdf.query.QueryResults.report(QueryResults.java:158) ~[sesame-query-4.0.0.jar:?] at org.openrdf.query.resultio.QueryResultIO.writeTuple(QueryResultIO.java:449) ~[sesame-queryresultio-api-4.0.0.jar:?] at com.complexible.stardog.protocols.http.server.io.ResponseBodyEncoders$13.encode(ResponseBodyEncoders.java:470) ~[stardog-protocols-http-server-4.2.3.jar:?] at com.complexible.stardog.protocols.http.server.io.ResponseBodyEncoders$2.encode(ResponseBodyEncoders.java:101) ~[stardog-protocols-http-server-4.2.3.jar:?] at com.complexible.stardog.protocols.http.annex.QueryPanelEncoder.encode(QueryPanelEncoder.java:112) ~[stardog-webconsole-annex-4.2.3.jar:?] at com.complexible.stardog.protocols.http.server.HttpMessageEncoder.write(HttpMessageEncoder.java:158) [stardog-protocols-http-server-4.2.3.jar:?] at io.netty.channel.AbstractChannelHandlerContext.invokeWrite(AbstractChannelHandlerContext.java:633) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.channel.AbstractChannelHandlerContext.access$1900(AbstractChannelHandlerContext.java:32) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.write(AbstractChannelHandlerContext.java:908) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.channel.AbstractChannelHandlerContext$AbstractWriteTask.run(AbstractChannelHandlerContext.java:893) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357) [netty-all-4.0.32.Final.jar:4.0.32.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112) [netty-all-4.0.32.Final.jar:4.0.32.Final] at java.lang.Thread.run(Unknown Source) [?:1.8.0_121] Caused by: java.util.NoSuchElementException at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154) ~[guava-18.0.jar:?] at com.google.common.collect.Iterators.find(Iterators.java:717) ~[guava-18.0.jar:?] at com.google.common.collect.Iterables.find(Iterables.java:646) ~[guava-18.0.jar:?] at com.clarkparsia.pellet.api.query.impl.DefaultQueryEngine.execute(DefaultQueryEngine.java:205) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.DefaultQueryEngine.execute(DefaultQueryEngine.java:104) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.DefaultQueryEngine.execute(DefaultQueryEngine.java:87) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.AbstractQueryEngine.visit(AbstractQueryEngine.java:104) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.AbstractQueryEngine.visit(AbstractQueryEngine.java:33) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.SelectQueryImpl.accept(SelectQueryImpl.java:43) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.clarkparsia.pellet.api.query.impl.AbstractQueryEngine.execute(AbstractQueryEngine.java:42) ~[stardog-reasoning-shared-4.2.3.jar:?] at com.complexible.stardog.reasoning.pellet.PelletUtils.executeQuery(PelletUtils.java:88) ~[stardog-reasoning-core-4.2.3.jar:?] at com.complexible.stardog.reasoning.pellet.PelletOp.computeNext(PelletOp.java:84) ~[stardog-reasoning-core-4.2.3.jar:?] at com.complexible.stardog.reasoning.pellet.PelletOp.computeNext(PelletOp.java:35) ~[stardog-reasoning-core-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:83) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SingleProjectionOp.computeNext(SingleProjectionOp.java:33) ~[stardog-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.OrderLimitOffset.sortedResults(OrderLimitOffset.java:163) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.OrderLimitOffset.computeNext(OrderLimitOffset.java:136) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.OrderLimitOffset.computeNext(OrderLimitOffset.java:47) ~[stardog-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SliceOp._hasNext(SliceOp.java:87) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SliceOp.computeNext(SliceOp.java:95) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.impl.SliceOp.computeNext(SliceOp.java:26) ~[stardog-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:115) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:25) ~[stardog-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:110) ~[stardog-4.2.3.jar:?] at com.complexible.stardog.plan.eval.operator.util.OpBasedBindingSetIteration.computeNext(OpBasedBindingSetIteration.java:34) ~[stardog-4.2.3.jar:?] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-18.0.jar:?] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-18.0.jar:?] at com.complexible.common.rdf.query.IteratorAsTupleQueryResult.hasNext(IteratorAsTupleQueryResult.java:77) ~[stardog-utils-rdf-4.2.3.jar:?] ... 15 more

Another issue is slowing reasoning query with IRIs. It happens when I run reasoning query with IRIs, where it takes up to 2 mins or even more. Is it normal or potentially faulty with my ontology?
Thanks!

2

I’m not quite sure what you mean by “reasining query with IRI’s” but I might be able to help you get your question answered more quickly. Can you share your queries and data or at least a minimal example that reproduces your problem?

3

Hi Zachary,
Thanks for your reply. If I switch on reasoning while querying things without rdfs:label (where stardog returns links/IRIs), it works, as shown in the picture:

Screen Shot 2017-03-31 at 14.21.36.png2262Ă—1324 142 KB

However, as I dricribed, it takes lots of time. So I am wondering if it is normal to take over a minute or more to run a reasoning query?

Another issue is if I query rdfs:label, such as

Select ?s ?o WHERE{ ?s rdfs:label ?o}
Stardog complains with Internal Server Error. Is this normal? Sorry I was going to attach an screen shot but I am not allowed.

Thanks!

4

So you get a stack trace when you include rdfs:label and reasoning but don’t get the stack trace when you remove rdfs:label? In addition you feel like running the query with reasoning takes an excessive amount of time to complete? Do I have that right?

It’s difficult to say what is normal since query time is going to depend on a combination of, among other things, the data, ontology, query, and the hardware you’re running it on.

An internal server error is never something you should expect to see and it seems like there may be an issue.

5

Yes. It seems that as long as I include rdfs:label in my SPARQL query, it does not support query with reasoning.

And yes again. Could it be possible that my ontology has some potential faults, even though it could do reasoning in Protoge? I reckon the hardware shouldn't be the problem- dual core processor and 8GB RAM are allocated to the virtual machine.

I do not know if Stardog doesn't support rdfs:label query with reasoning or?

6

Hi,

It should be showing you an error for this, but try running the query without all of the PREFIX definitions in the textbox. The web console has a separate control above the textbox for defining prefixes, and it doesn’t like them being defined again.

That said, with a clean 4.2.4 install I am able to use reasoning in queries that contain rdfs:label just fine. If you could send us a small dataset and a query that reliably reproduce this issue, I’ll gladly take a look at it.

7

Hi,

I am aware of the fact that PREFIX definitions should not be defined again so I left the separate control blank, otherwise it would notice me that I should not re-define prefix.

And thank you in advance! I am new to this community, so can you tell me how to send you the dataset? I cannot even execute the simplest one with reasoning like

Select ?s ?o WHERE{ ?s rdfs:label ?o}
But it works fine without reasoning. Thank you!
8

As far as sending the dataset, if you are unable to put it here as an attachment, you could try a service like refheap or pastebin and make it private.

But all that aside, does your query work if you try it via the CLI instead of the webconsole? i.e., stardog query -r myDb "select ?s ?o where {?s rdfs:label ?o}"?

9

I tried it and it showed me this

Screen Shot 2017-04-03 at 13.31.24.png1252Ă—226 10.7 KB

Ontology file

10

Hi,

After looking into this issue further, it is actually a bug in our DL reasoning. Were your ontology an SL (RL, EL, QL) ontology, you wouldn’t be seeing this.

Thanks for the report! I’ve filed a bug internally, we’ll continue looking at it and report back here with any news or workarounds. As a temporary workaround for this, you could use a different predicate. For example:

INSERT {?s :myTempRdfsLabel ?o} WHERE {BIND(rdfs:label as ?p) . ?s ?p ?o}

This would let you query on your temp variable for the same results without having to rely specifically on rdfs:label.

11

Hi,

Thanks for your reply! Is it going to be fixed in the future or it has been fixed in 4.2.4? Currently, I am still running 4.2.3.

12

No, it is not fixed as of 4.2.4. The fix will roll out sometime during the 5.x lifecycle.

13

I see. Thanks a lot!

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.