com.complexible.stardog.StardogException: java.lang.String cannot be cast to java.lang.Boolean

Support Bug
1

After migrating production database (data can not be shared) from Stardog 6 to Stardog 7 -- using backup/restore functionality -- the database throws an exception to a simple select * where {?s ?p ?o} limit 5 query executed via Stardog Studio:

ERROR 2019-11-04 13:59:47,739 [stardog-user-8] com.stardog.http.server.undertow.ErrorHandling:writeError(138): Unexpected error on the server
com.complexible.stardog.StardogException: java.lang.String cannot be cast to java.lang.Boolean
	at com.complexible.stardog.StardogKernel.getConnection(StardogKernel.java:1126) ~[stardog-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.KernelHttpService$ConnectionOptions.connect(KernelHttpService.java:117) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.KernelHttpService.openConnection(KernelHttpService.java:68) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.SPARQLProtocol.executeQuery(SPARQLProtocol.java:111) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.SPARQLProtocol.post(SPARQLProtocol.java:92) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.3.0.jar:1.3.0]
	at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.3.0.jar:1.3.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
	at com.complexible.stardog.StardogKernel.getConnection(StardogKernel.java:1060) ~[stardog-7.0.2.jar:?]
	... 10 more
ERROR 2019-11-04 13:59:55,308 [stardog-user-1] com.stardog.http.server.undertow.ErrorHandling:writeError(138): Unexpected error on the server
com.complexible.stardog.StardogException: java.lang.String cannot be cast to java.lang.Boolean
	at com.complexible.stardog.StardogKernel.getConnection(StardogKernel.java:1126) ~[stardog-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.KernelHttpService$ConnectionOptions.connect(KernelHttpService.java:117) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.KernelHttpService.openConnection(KernelHttpService.java:68) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.SPARQLProtocol.executeQuery(SPARQLProtocol.java:111) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.complexible.stardog.protocols.http.server.SPARQLProtocol.post(SPARQLProtocol.java:92) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-7.0.2.jar:?]
	at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.3.0.jar:1.3.0]
	at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.3.0.jar:1.3.0]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Boolean
	at com.complexible.stardog.StardogKernel.getConnection(StardogKernel.java:1060) ~[stardog-7.0.2.jar:?]
	... 10 more

I have executed stardog-admin db offline stardog && stardog-admin db repair stardog, which took about 2h and yielded no results (still the same exception).

I have executed stardog-admin db optimize stardog as well to see if this helps, but the query still fails with the same exception.

In addition to that restore process on stardog 7 was painfully slow:

# 8 cores, ssd drive
# STARDOG_SERVER_JAVA_ARGS=-Xms8g -Xmx8g -XX:MaxDirectMemorySize=16g
Node XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX: Successfully restored database 'stardog' from Backup(/backups/20XX-XX-XX) in 02:27:57.736.

The size of the directories after the backup restoration:

bash-5.0# du -d 1 -h
4.0K	./tmp_sst_data
16.0K	./system
4.0K	./.spilling
5.3G	./data
466.5M	./stardog
29.2G	.

What can be attempted to fix the database?

1 Like
2

Hi,

We've seen an error like this before with a migration. Try the following:

export AUTH=`echo -n admin:admin | base64` # Replace with your actual user:password, obviously don't include in output
clear # Just to be sure
# Again, replace port and myDb with the correct values
curl --url http://localhost:<port>/admin/databases/<myDb>/options \
  --header "Authorization: Basic $AUTH"

Take a look in the output and see if there's a boolean option that happens to have a string value. In previous cases it was specifically "security.named.graphs": "true",

Once you find the rogue values, you would just need to toggle the option back and forth in the command line to massage it back to a proper boolean value:

stardog-admin metadata set myDb -o security.named.graphs=false
stardog-admin metadata set myDb -o security.named.graphs=true
3

Hi Stephen,

that was exactly the problem. Resetting the value fixed it. Thanks for the hint.

Is it a known bug? Does it happen always during 6 --> 7 db migration?

4

This is exactly the second time we've heard of it happening, so we're not entirely sure of the cause. Most migrations from 6 -> 7 go just fine.

5

Okay, if it is not really reproducible, I think, we should not spend time on this. Thanks for the support!

6

I was able reproduce it:

This happens in Stardog Studio Version 1.13.1 (1.13.1.13021)
Execute a query on a stardog 6.2.3
Then switch to stardog 7.0.2, execute a query
The switch back to stardog 6.2.3 and execute the query -> and there is the error message

Restarting Stardog studio solves the problem.

7

Ok, now i got this issue on my stardog 6.2.3 databases on my test instance. Not sure if the studio is causing this, but it might.