Steps to Reproduce:
We are using the wdqs 0.3.10 docker image (wikibase/wdqs:0.3.10) to load the latest RDF dump into a BlazeGraph journal. We have a reasonable sized hardware environment with sufficient memory, CPU and disk space. We are roughly following steps as defined on https://addshore.com/2019/10/your-own-wikidata-query-service-with-no-limits-part-1/
After about 80% of the data is loaded, we are seeing exception in the blazegraph log, looking like:
```
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.AssertionError: Record exists for offset in cache: offset=2147483616
at com.bigdata.rdf.rio.StatementBuffer.flush(StatementBuffer.java:955)
at com.bigdata.rdf.sail.BigdataSail$BigdataSailConnection.flushStatementBuffers(BigdataSail.java:4152)
```
We tried to load the data also with slightly different memory settings, or chunking settings during the munge process, same result.
After the third attempt we have tried to investigate and searched various sources on the internet for information. In the end we found the solution in the following official patches applied to the main WDQS journal file configuration:
https://gerrit.wikimedia.org/r/#/c/wikidata/query/rdf/+/512890/
The corresponding issue description can be found in https://phabricator.wikimedia.org/T213210
It turns out that the BTree configuration in the official WDQS Blazegraph configuration has been adjusted (particularly the BTree branching factors) to avoid allocation limits.
This adjustment is missing in the RWStore.properties bundled in the current docker releases.
We have been able to successfully load the March Wikidata dump by supplying the updated RWStore.properties to our container, basically having the same configuration as in the productive master.
Expected result:
Update the RWStore.properties file to allow a successful loading proces