On 18/05/13 16:09, Christian Jauvin wrote:
Hi,
I'm using TDB (Jena 2.10) and this simple SPARQL query (run with
"tdbquery") over a store of ~1000 triples (which is actually a dump of
an OWL ontology):
select (count(?x) as ?cnt)
where { ?x rdfs:subClassOf* ?y }
gives the error:
11:03:03 ERROR TDB ::
ObjectFileStorage.read[nodes.dat](16221)[filesize=49330][file.size()=49330]:
Impossibly large object : 825189752 bytes >
filesize-(loc+SizeOfInt)=33105
com.hp.hpl.jena.tdb.base.file.FileException:
ObjectFileStorage.read[nodes.dat](16221)[filesize=49330][file.size()=49330]:
Impossibly large object : 825189752 bytes >
filesize-(loc+SizeOfInt)=33105
at
com.hp.hpl.jena.tdb.base.objectfile.ObjectFileStorage.read(ObjectFileStorage.java:346)
at com.hp.hpl.jena.tdb.lib.NodeLib.fetchDecode(NodeLib.java:78)
[...]
whereas the same query, over the same ontology in Protege runs fine
(and yields a count of 3062, proving that this is not an "impossibly
large object").
Note that the same query, with the non-transitive version of the operator:
select (count(?x) as ?cnt)
where { ?x rdfs:subClassOf ?y }
runs fine in TDB (and yields 170).
Thanks,
Christian
Hi Christian,
It looks like the node table is corrupted from a previous run after
non-transactional update and exisitng the JVM without calling
TDB.sync(dataset)
The "Impossibly large object" is because it's reading bytes making up
another node as a length count.
> select (count(?x) as ?cnt)
> where { ?x rdfs:subClassOf* ?y }
> select (count(?x) as ?cnt)
> where { ?x rdfs:subClassOf ?y }
In the first case, the system does need to access the node value of ?y
because * is done by a general engine on nodes where as the plain
pattern does not access the string that represents ?y so never touches
some parts of the node table.
Andy
