Stardog VM Size and RAM for VirtualGraphs with 50 million records

charbe...@gmail.com

unread,

Sep 20, 2016, 6:08:41 PM9/20/16

to Stardog

Hello,

I am trying to figure out what is the best configuration for Stardog in order to query a virtual graph which is pretty simple with only 3 columns.

The virtual graph is on a Azure SQL Server P1 configuration.

I installed Stardog on a linux VM on Azure with DS2 v2 with 2 cores and 7 GB memory. I am having connection timeouts on the virtual graph part even after configuring the timeout to 30 000 sec.

my qyeru looks like the following,

SELECT DISTINCT ?a

WHERE

{

?a a qt:Server.

?a qt:hasPoint ?point.

?point qt:hasType pdm:WHr_I.

GRAPH <virtual://db2>

{

?b qt:hasValue ?value.

}

filter (?a = ?b)

}

group by ?a

Thank you,

Charbel

Jess Balint

unread,

Sep 20, 2016, 6:44:54 PM9/20/16

to sta...@clarkparsia.com

Charbel,

How many unique results do anticipate will be returned from the virtual graph query? The filter will be executed in Stardog. We don't yet have an optimization to handle this type of join between the local RDF graph and a remote RDBMS viewed as a virtual graph.

Jess

--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+unsubscribe@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

Charbel Kaed

unread,

Sep 20, 2016, 6:52:55 PM9/20/16

to Stardog

Hi Jess,

I am expecting between 500.000 to 1 million records.

would you recommend that I move the data (50 million record) to Stardog instead?

Thank you,

stardog+u...@clarkparsia.com

Jess Balint

unread,

Sep 20, 2016, 6:58:07 PM9/20/16

to sta...@clarkparsia.com

Charbel,

You have several options. You can materialize the entire virtual graph in Stardog or only the "qt:hasValue" property. The queries will certainly be faster if the data is in Stardog. The balance is between query speed and copying of data to Stardog. If your dataset is (relatively) static, materializing in Stardog is a good option. How many unique values for "?a" do you anticipate?

Jess

stardog+unsubscribe@clarkparsia.com

Charbel Kaed

unread,

Sep 20, 2016, 7:08:34 PM9/20/16

to Stardog

Jess,

For now, I have 230 unique values for a. But 50 million records in the virtual graph.

I can consider the data is static for now. However, I received 230 entries every 5 minutes.

Jess Balint

unread,

Sep 20, 2016, 7:27:56 PM9/20/16

to sta...@clarkparsia.com

Since your virtual graph data is static, it would be good to import into Stardog. The virtual graph data will be available to join with new "qt:Server" individuals as they arrive. You can materialize a subset of virtual graph data in Stardog using SPARQL (e.g. insert { graph <localCopy> { ?b qt:hasValue ?v } } where { graph <virtual://db2> { ?b qt:hasValue ?value } }) or the entire virtual graph with the standard ADD/COPY commands as detailed in [1].

Jess

[1] http://docs.stardog.com/#_materializing_virtual_graphs

Zachary Whitley

unread,

Sep 20, 2016, 7:40:43 PM9/20/16

to sta...@clarkparsia.com

Just a couple of things to add. Do you have any indexes on the table? Maybe I'm missing something but wouldn't the following be equivalent but possibly faster?

SELECT DISTINCT ?a

WHERE

{

?a a qt:Server.

?a qt:hasPoint ?point.

?point qt:hasType pdm:WHr_I.

GRAPH <virtual://db2>

{

?a qt:hasValue ?value.

}

group by ?a

stardog+u...@clarkparsia.com

For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

---
You received this message because you are subscribed to the Google Groups "Stardog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

Jess Balint

unread,

Sep 20, 2016, 7:48:17 PM9/20/16

to sta...@clarkparsia.com

On Tue, Sep 20, 2016 at 6:40 PM, Zachary Whitley <zachary...@gmail.com> wrote:

Just a couple of things to add. Do you have any indexes on the table? Maybe I'm missing something but wouldn't the following be equivalent but possibly faster?

Stardog will execute both forms of the query in the same way. The issue is that virtual graph queries joined with the local RDF graph aren't well optimized. The more selective the virtual graph query the better.

Jess

---
You received this message because you are subscribed to the Google Groups "Stardog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stardog+unsubscribe@clarkparsia.com.

charbe...@gmail.com

unread,

Sep 20, 2016, 8:26:28 PM9/20/16

to sta...@clarkparsia.com

Thank you Jess and Zachary,

@Zachary: I will try this query to check if it makes any difference.

@Jess: I would prefer not to import the virtual graph into Stardog as it is getting updated every 5 min. But will try it to have an idea about performance.

I guess with the materialization operation copies the data from the RDBMS and indexes it locally in Stardog?

Thank you,

Charbel

stardog+u...@clarkparsia.com

For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en
---

You received this message because you are subscribed to a topic in the Google Groups "Stardog" group.
To unsubscribe from this topic, visit https://groups.google.com/a/clarkparsia.com/d/topic/stardog/J00Fc89Q5aw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to stardog+u...@clarkparsia.com.

Jess Balint

unread,

Sep 20, 2016, 8:29:49 PM9/20/16

to sta...@clarkparsia.com

On Tue, Sep 20, 2016 at 7:26 PM, <charbe...@gmail.com> wrote:

Thank you Jess and Zachary,

@Zachary: I will try this query to check if it makes any difference.

@Jess: I would prefer not to import the virtual graph into Stardog as it is getting updated every 5 min. But will try it to have an idea about performance.
I guess with the materialization operation copies the data from the RDBMS and indexes it locally in Stardog?

Yes, that's correct.

Jess

You received this message because you are subscribed to a topic in the Google Groups "Stardog" group.
To unsubscribe from this topic, visit https://groups.google.com/a/clarkparsia.com/d/topic/stardog/J00Fc89Q5aw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to stardog+unsubscribe@clarkparsia.com.

Charbel Kaed

unread,

Sep 21, 2016, 4:00:21 PM9/21/16

to Stardog

@Zachary: I tried the query you suggested, it still the same timeout query.

@Jess: I started the virtual graph import,

According to [1], 1 billion triples would require 4GB of JVM memory and 8GB of off-heap memory.

in my RDBMS I have 50 million records, every record has 3 elements a, b, c with a and b as primary keys.

so I assumed that every record will generate the following

a hasBlankNode _:bn#someID,

_:bn#someID hasR2RMLProperty1 b,

_:bn#someID hasR2RMLProperty c,

Which means for every record in my RDBMS I will have 3 triples.

Which makes the total 50 million records x 3 triples = 150 million triples.

any hints to how much heap mem and jvm mem would be required?

[1] http://docs.stardog.com/#_memory_usage

With the following configuration, I have the following error:

STARDOG_JAVA_ARGS="-Xmx5g -Xms5g"

./stardog-admin virtual import BOC-SBOXVSFD-SDF2 semantic.properties semantic.ttl

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000755580000, 1789394944, 0) failed; error='Cannot allocate memory' (errno=12)

#

# There is insufficient memory for the Java Runtime Environment to continue.

# Native memory allocation (mmap) failed to map 1789394944 bytes for committing reserved memory.

# An error report file with more information is saved as:

# /home/osadmin/stardog-4.1.3/bin/hs_err_pid42821.log

Thank you,

Zachary Whitley

unread,

Sep 21, 2016, 4:11:14 PM9/21/16

to Stardog

Like Jess mentioned, the query optimizer is going to generate the same query. I didn't know what exactly the query optimizer was having a hard time with. (I'm guessing it has to do with not being able to generate cardinality estimates over logical tables)

How much ram do you have on your server? It looks like you didn't specify an off heap size -XX:MaxDirectMemorySize=???

I'm not sure exactly what it would do in that case. I'd guess it would use the default.

--

Jess Balint

unread,

Sep 21, 2016, 4:23:09 PM9/21/16

to sta...@clarkparsia.com

Can you share this crash log? How much total memory is available on your system?

Jess

Thank you,

Zachary Whitley

unread,

Sep 21, 2016, 4:25:49 PM9/21/16

to Stardog

I just noticed that he's running on a VM. I have seen similar issues while running on a VM but unfortunately I'm unable to share the logs. :(

Charbel Kaed

unread,

Sep 21, 2016, 4:51:50 PM9/21/16

to Stardog

@Zachary was right, I specified the
-XX:MaxDirectMemorySize and it worked.

We are so close :)

I am having another issue now with the import.

I did this first:

./stardog-admin virtual add --format r2rml semantic.properties semantic.ttl

then this:

./stardog-admin virtual import --format r2rml BOC-SBOXVSFD-SDF semantic.properties semantic.ttl

I have got this error:
"Too many pattern letters: a"

I am not sure what it means?

Here is my r2rml file:

@prefix rr: <http://www.w3.org/ns/r2rml#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix device: <http://www.mycompany.com/partner/Devices#> .

@prefix boc: <http://www.mycompany.com/Clients/BoC#> .

@prefix qt: <http://www.mycompany.com/global/CoreSE_Quantity#> .

@base <http://example.com/base/> .

a rr:TriplesMap;

rr:logicalTable [ rr:tableName "sqldb4" ];

rr:subjectMap [ rr:template "http://www.mycompany.com/Clients/BoC#{\"id\"}" ;

rr:class qt:Elements ];

rr:predicateObjectMap [

rr:predicate boc:id ;

rr:objectMap [ rr:column "\"id\""; rr:datatype xsd:string ]

];

rr:predicateObjectMap [

rr:predicate qt:hasparam1 ;

rr:objectMap [ rr:column "\"param1\""; rr:datatype xsd:double ]

];

rr:predicateObjectMap [

rr:predicate qt:hasparam2 ;

rr:objectMap [ rr:column "\"param2\""; rr:datatype xsd:double ]

].

Jess Balint

unread,

Sep 21, 2016, 5:09:39 PM9/21/16

to sta...@clarkparsia.com

On Wed, Sep 21, 2016 at 3:51 PM, Charbel Kaed <charbe...@gmail.com> wrote:

@Zachary was right, I specified the
-XX:MaxDirectMemorySize and it worked.

We are so close :)

Great.

I am having another issue now with the import.

I did this first:
./stardog-admin virtual add --format r2rml semantic.properties semantic.ttl

then this:
./stardog-admin virtual import --format r2rml BOC-SBOXVSFD-SDF semantic.properties semantic.ttl

I have got this error:
"Too many pattern letters: a"

I am not sure what it means?

This is an issue with VG materialization from SQL Server that is fixed in Stardog 4.2 which we plan to release around the middle of next week. In the meantime, you can disable the import optimizations leading to this error by placing "import.optimize=false" in your properties file.

Jess

Here is my r2rml file:

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix device: <http://www.mycompany.com/partner/Devices#> .
@prefix boc: <http://www.mycompany.com/Clients/BoC#> .
@prefix qt: <http://www.mycompany.com/global/CoreSE_Quantity#> .
@base <http://example.com/base/> .

<SQLDBTriplesMap>
a rr:TriplesMap;
rr:logicalTable [ rr:tableName "sqldb4" ];
rr:subjectMap [ rr:template "http://www.mycompany.com/Clients/BoC#{\"id\"}" ;
rr:class qt:Elements ];
rr:predicateObjectMap [
rr:predicate boc:id ;
rr:objectMap [ rr:column "\"id\""; rr:datatype xsd:string ]
];
rr:predicateObjectMap [
rr:predicate qt:hasparam1 ;
rr:objectMap [ rr:column "\"param1\""; rr:datatype xsd:double ]
];
rr:predicateObjectMap [
rr:predicate qt:hasparam2 ;
rr:objectMap [ rr:column "\"param2\""; rr:datatype xsd:double ]
].

--

Charbel Kaed

unread,

Sep 22, 2016, 11:03:38 AM9/22/16

to Stardog

Hello,

I tried the import but got timeout, the performance of the SQL where 100% CPU while doing the import for about an hour then I got timeout exception.

I resized my Linux VM which is running nothing but Stardog to 8 cores and 56 GB RAM and 800 GB SSD. Any recommendation on the JVM and Off Memory heap size?

Thank you,

Zachary Whitley

unread,

Sep 22, 2016, 11:14:41 AM9/22/16

to Stardog

What exactly did you run to do the import?

--

-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+unsubscribe@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

Charbel Kaed

unread,

Sep 22, 2016, 11:22:03 AM9/22/16

to Stardog

I first created the virtual graph:

./stardog-admin virtual add --format r2rml semantic.properties semantic.ttl

then import it?

Charbel Kaed

unread,

Sep 22, 2016, 11:23:33 AM9/22/16

to Stardog

This is the charts on the SQL Azure side:

Capture.PNG

Jess Balint

unread,

Sep 22, 2016, 12:08:21 PM9/22/16

to sta...@clarkparsia.com

It doesn't appear to be a memory issue at this point. What do you see in the log when the timeout occurs?

Jess

Charbel Kaed

unread,

Sep 22, 2016, 1:42:33 PM9/22/16

to Stardog

Hello Jess,

I got this error message: There was a fatal failure during preparation of d66f2490-49e0-4801-ba77-1eff6cc15a9b There was an error while indexing the new data

in the log got the following:

INFO 2016-09-22 16:31:51,017 [main] com.complexible.stardog.virtual.DefaultVirtualGraphRegistry:syncCache(184): Initializing R2RML registry

INFO 2016-09-22 16:31:51,957 [main] com.complexible.stardog.virtual.DefaultVirtualGraphRegistry:syncCache(193): Loaded R2RML registry with 3 sources

INFO 2016-09-22 16:31:52,544 [main] com.complexible.stardog.StardogKernel:start(1864): Initializing Stardog

WARN 2016-09-22 16:31:52,567 [main] com.complexible.stardog.metadata.MetadataIO:readBytes(260): Unrecognized option in the metadata: search.version

WARN 2016-09-22 17:09:08,582 [Stardog.Executor-3] com.complexible.stardog.plan.eval.operator.impl.ModifyOperatorImpl:varType(442): Cannot determine the type of the variable in the update query: null

ERROR 2016-09-22 17:16:13,266 [Stardog.Executor-3] com.complexible.tx.api.impl.DefaultTransaction:computePrepareResult(489): There was a fatal failure during preparation of d66f2490-49e0-4801-ba77-1eff6cc15a9b

com.complexible.tx.api.ResourceTransactionException: There was an error while indexing the new data

at com.complexible.stardog.search.db.ConnectableSearchConnectionImpl$SearchIndexResourceTransaction.prepare(ConnectableSearchConnectionImpl.java:410) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.tx.api.BaseResourceTransaction.prepare(BaseResourceTransaction.java:187) ~[stardog-4.1.3.jar:?]

at com.complexible.tx.api.impl.DefaultTransaction.computePrepareResult(DefaultTransaction.java:473) ~[stardog-4.1.3.jar:?]

at com.complexible.tx.api.impl.DefaultTransaction.runPreparePhase(DefaultTransaction.java:439) ~[stardog-4.1.3.jar:?]

at com.complexible.tx.api.impl.DefaultTransaction.commit(DefaultTransaction.java:330) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.db.DatabaseConnectionImpl.commit(DatabaseConnectionImpl.java:405) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.db.DelegatingTransactionalConnectableConnection.commit(DelegatingTransactionalConnectableConnection.java:68) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.UpdateSequenceOperatorImpl.computeNext(UpdateSequenceOperatorImpl.java:89) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.UpdateSequenceOperatorImpl.computeNext(UpdateSequenceOperatorImpl.java:29) ~[stardog-4.1.3.jar:?]

at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.1.3.jar:?]

at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:87) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.util.AutoCloseOperator.computeNext(AutoCloseOperator.java:25) ~[stardog-4.1.3.jar:?]

at com.complexible.common.collect.AbstractSkippingIterator.tryToComputeNext(AbstractSkippingIterator.java:143) ~[stardog-utils-common-4.1.3.jar:?]

at com.complexible.common.collect.AbstractSkippingIterator.hasNext(AbstractSkippingIterator.java:130) ~[stardog-utils-common-4.1.3.jar:?]

at com.google.common.collect.Iterators.size(Iterators.java:191) ~[guava-18.0.jar:?]

at com.complexible.stardog.plan.eval.QueryEngine.executeUpdate(QueryEngine.java:165) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.query.DefaultQueryFactory$UpdateQueryImpl.execute(DefaultQueryFactory.java:263) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.query.DefaultQueryFactory$UpdateQueryImpl.execute(DefaultQueryFactory.java:242) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.query.DelegatingUpdateQuery.execute(DelegatingUpdateQuery.java:139) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.db.DatabaseImpl$TimerPauseUpdate.execute(DatabaseImpl.java:1571) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.db.DatabaseImpl$TimerPauseUpdate.execute(DatabaseImpl.java:1559) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.query.DelegatingUpdateQuery.execute(DelegatingUpdateQuery.java:139) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.StardogKernel$SecuredUpdateQuery.execute(StardogKernel.java:3708) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.StardogKernel$SecuredUpdateQuery.execute(StardogKernel.java:3695) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.protocols.server.SPECServerFunction.query(SPECServerFunction.java:510) ~[stardog-protocols-spec-server-4.1.3.jar:?]

at com.complexible.stardog.protocols.server.SPECServerFunction.handleMessage(SPECServerFunction.java:149) ~[stardog-protocols-spec-server-4.1.3.jar:?]

at com.complexible.common.protocols.server.rpc.ServerHandler.lambda$handleMessage$1(ServerHandler.java:338) ~[stardog-protocols-api-server-4.1.3.jar:?]

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_91]

at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_91]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_91]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_91]

at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91]

Caused by: com.complexible.stardog.search.IndexingException: /tmp/1474561960287-0/sd1474561960289-0 (No such file or directory)

at com.complexible.stardog.search.waldo.DefaultIndexer.index(DefaultIndexer.java:209) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:134) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:108) ~[stardog-search-waldo-4.1.3.jar:?]

... 4 more

Caused by: com.complexible.stardog.plan.eval.operator.OperatorException: /tmp/1474561960287-0/sd1474561960289-0 (No such file or directory)

at com.complexible.stardog.plan.eval.operator.util.DiskSolutionSequence.iterator(DiskSolutionSequence.java:99) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.util.DiskSolutionSequence.iterator(DiskSolutionSequence.java:34) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.ModifyOperatorImpl$CachedStmtSource.createOperator(ModifyOperatorImpl.java:275) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.ModifyOperatorImpl$AbstractStmtSource.statements(ModifyOperatorImpl.java:306) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.search.waldo.DefaultIndexer.index(DefaultIndexer.java:168) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:134) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:108) ~[stardog-search-waldo-4.1.3.jar:?]

... 4 more

Caused by: java.io.FileNotFoundException: /tmp/1474561960287-0/sd1474561960289-0 (No such file or directory)

at java.io.FileInputStream.open0(Native Method) ~[?:1.8.0_91]

at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:1.8.0_91]

at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:1.8.0_91]

at com.complexible.stardog.plan.eval.operator.util.DiskSolutionSequence.iterator(DiskSolutionSequence.java:96) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.util.DiskSolutionSequence.iterator(DiskSolutionSequence.java:34) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.ModifyOperatorImpl$CachedStmtSource.createOperator(ModifyOperatorImpl.java:275) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.plan.eval.operator.impl.ModifyOperatorImpl$AbstractStmtSource.statements(ModifyOperatorImpl.java:306) ~[stardog-4.1.3.jar:?]

at com.complexible.stardog.search.waldo.DefaultIndexer.index(DefaultIndexer.java:168) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:134) ~[stardog-search-waldo-4.1.3.jar:?]

at com.complexible.stardog.search.IndexingStrategy$RunIndexer.call(IndexingStrategy.java:108) ~[stardog-search-waldo-4.1.3.jar:?]

... 4 more

ERROR 2016-09-22 17:16:13,287 [Stardog.Executor-3] com.complexible.stardog.db.DatabaseConnectionImpl:commit(414): There was an error committing the transaction, all changes were rolled back successfully

com.complexible.tx.api.HeuristicRollbackException: There was a fatal failure during preparation of d66f2490-49e0-4801-ba77-1eff6cc15a9b There was an error while indexing the new data

at com.complexible.tx.api.impl.DefaultTransaction.runPreparePhase(DefaultTransaction.java:444) ~[stardog-4.1.3.jar:?]