500 Server Error upon consistency check with automatic reasoning is enabled

Support Bug
1

To reproduce:

  • Create a new database, with all default settings except ‘Automatic consistency checking’: enabled
  • Do a consistency check (stardog reasoning consistency <dbname>)
  • Observe ‘There was an unexpected error on the server.’ as only line of output

Note this happens both with and without adding any data.

stardog.log :

WARN  2018-04-14 21:26:24,556 [stardog-user-17] com.complexible.stardog.StardogKernel:createDatabase(1416): Following options cannot be set at creation time and/or contradict with other options: [index.persist.sync]
INFO  2018-04-14 21:26:28,092 [stardog-user-17] com.complexible.stardog.StardogKernel:write(77): Successfully created database 'ddd'.
ERROR 2018-04-14 21:26:42,406 [stardog-user-18] com.stardog.http.server.undertow.ErrorHandling:writeError(180): Unexpected error on the server
java.lang.NullPointerException: null
	at com.complexible.stardog.reasoning.blackout.BlackoutConnection.getConsistency(BlackoutConnection.java:334) ~[stardog-reasoning-core-5.2.2.jar:?]
	at com.complexible.stardog.reasoning.blackout.BlackoutConnection.isConsistent(BlackoutConnection.java:328) ~[stardog-reasoning-core-5.2.2.jar:?]
	at com.complexible.stardog.reasoning.ConnectableReasonerConnectionImpl.isConsistent(ConnectableReasonerConnectionImpl.java:195) ~[stardog-reasoning-core-5.2.2.jar:?]
	at com.complexible.stardog.protocols.http.reasoning.server.ReasoningHttpService.isConsistent(ReasoningHttpService.java:203) ~[stardog-reasoning-protocols-http-server-5.2.2.jar:?]
	at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:196) ~[stardog-protocols-http-server-5.2.2.jar:?]
	at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) ~[shiro-core-1.2.3.jar:1.2.3]
	at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) ~[shiro-core-1.2.3.jar:1.2.3]
	at com.stardog.http.server.undertow.ErrorHandling.lambda$safeDispatch$1(ErrorHandling.java:71) ~[stardog-protocols-http-server-5.2.2.jar:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_162]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_162]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_162]

I see the ‘Following options cannot be set at creation time and/or contradict with other options: [index.persist.sync]’, but I don’t understand why that would be the case. If there is a good reason, I think the user should be warned in the UI and the API should throw a descriptive error, not 500.

Using stardog 5.2.2 on ubuntu 17.10 .

edit: is also the case with stardog 5.2.3

2

Hi, apologies for the delay in a response here. Thanks for this detailed report! I am able to reproduce this issue with my local 5.2.3 instance and am currently looking into its cause, to be fixed in a future release. If in the process I discover a workaround, I’ll be sure to update here.

Edit: The index.persist.sync warning is actually a red herring here. It simply means that that setting is incompatible with disk indexes, which is the default. I could only see it, however, when enabling that option as well

3

Thanks for the reply. I tried using memory indexes instead, but still the same problem.

Perhaps my approach is not right for my goal:

I want to configure my database in such a way that I can both do stardog reasoning consistency <dbname> at any time, AND have automatic consistency check such that any database operation that would lead to an inconsistent state would be rejected. This seems like a common use-case so I’m guessing my configuration wasn’t right.

How do I need to configure my database to achieve this?

4

It looks like what you want is Integrity Constraint Violation, specifically with icv.consistency.automatic=true so that ICV will also check database consistency.

5

Thank you! It seems I also need some other options, but now in the end transactions are refused when they lead to an inconsistent post-state. This config made it work for me: icv.consistency.automatic=true, icv.enabled=true, icv.reasoning.enabled=true. The naming is a bit confusing, it’s not clear to me what the difference between these settings are. But, it works! :slight_smile:

6

+1 for the naming being confusing. I get that icv.reasoning.enabled allows reasoning to satisfy constraints and icv.enabled is “guard mode” where transactions that violate constraints are rolled back but I’ve never felt that I know what exactly icv.consistency.automatic is. The docs say “Enables automatic ICV consistency check as part of transactions.” which sounds like “guard mode” but isn’t because icv.enabled says “Determines whether ICV is active for the database; if true, all database mutations are subject to IC validation (i.e., “guard mode”).”. Is it saying it enables you to check consistency with constraints but doesn’t enforce them? In that case you would think that would be what icv.enabled would be.