On 03/09/13 15:48, Andy Seaborne wrote:
Hi Stuart,
Thanks - I'll need to find time to create his here. Fro your
description it might be more an issue about the inf model not properly
supporting concurrent read access (and unrelated to the earlier issues,
from the point-of-view of internal implementation) but it'll need
investigation.
More complicated that the usual bugs!
I think I've tracked down both issues that combine to give this. It was
a combination of not passing clearing up sync calls down the stack of
datasets/graphs and the way Fuseki decided whether transactions were
safe or not (it needs a real abort to be able to fully stream updates).
The code in Fuseki is now very, and slightly overly, cautious as to when
it will assume transactional storage and when it will use locking and
sync'ing. Your example now works for me; there was a timing aspect to
it as well.
The updates aren't fully transactional for text-over-inf-over-TDB-graph.
The inference graph that gets in the way currently. This should be
fixable (JENA-530) but there is fix in there for now.
New Fuseki snapshot built.
>> 4) Stop Fuseki -- (I'm sending SIGTERM to the JVM).
After updates, the changes are flushed to disk so when there are no
active updates it is safe to stop the server in anyway you want. It's
not as safe as full ACID transactions yet.
Andy
Andy
On 02/09/13 16:15, Stuart Taylor wrote:
Hi Andy,
I've put together a more complete test case that hopefully you can
replicate. I'm running this on a clean copy of Fuseki extracted from
jena-fuseki-1.0.0-20130902.080009-8-distribution.tar.gz.
The test seems to depend only on the OWL part of schema and making a
query that triggers some rules in the inference graph. Also the
exception isn't thrown on the first time Fuseki is started after loading
the data, but is each time it is started after that. I've cut my dataset
down significantly so that there's a single owl:SymmetricProperty, which
also appears in the query, and then a bunch of direct sub properties.
I've attached the dataset, assembler file and the log from stdout.
1) Load the data and create the text index:
java -cp fuseki-server.jar tdb.tdbloader --tdb=hc-config-text.ttl
test-dataset.nt
java -cp fuseki-server.jar jena.textindexer --desc=hc-config-text.ttl
2) Start Fuseki:
./fuseki-server --config=hc-config-text.ttl --verbose
3) Run the queries:
./s-update --service http://localhost:3030/dataset/update 'prefix :
<http://example.org/fuseki-test.ttl#> insert data { <o1> :p <o2> }'
./s-query --service http://localhost:3030/dataset/query 'prefix :
<http://example.org/fuseki-test.ttl#> select * { <o1> :p ?o }'
(All okay up to this point).
4) Stop Fuseki -- (I'm sending SIGTERM to the JVM).
5) Start Fuseki:
./fuseki-server --config=hc-config-text.ttl --verbose
6) Run the queries a second time:
./s-update --service http://localhost:3030/dataset/update 'prefix :
<http://example.org/fuseki-test.ttl#> insert data { <o1> :p <o2> }'
./s-query --service http://localhost:3030/dataset/query 'prefix :
<http://example.org/fuseki-test.ttl#> select * { <o1> :p ?o }'
This time the SELECT query causes a concurrent modification exception.
Cheers,
Stuart.
