openRDF.org Issue Tracker

[SES-572] A null index specification for an existing native store should mean to use the existing indices

Fri, 26 Sep 2008 11:32:39 +0200 (CEST)

Currently, passing null or the empty string as the index specification string to the NativeStore constructor is interpreted as the default index string "spoc posc" (I guess). In case of an existing store, other indices may exist, and they are discarded. The existing indices are already stored in a properties file, but this value is never read. That value, if existing, should be taken as the default, instead of the mentioned "spoc posc".

[SES-652] Calling RDFFormat.getFileExtensions() returns MIME Types

Wed, 17 Dec 2008 13:56:39 +0100 (CET)

Calling RDFFormat.getFileExtensions() returns the same as RDFFormat.getMIMETypes. This is due to a copy+paste bug in http://repo.aduna-software.org/svn/info.aduna/commons/lang/trunk/src/main/java/info/aduna/lang/FileFormat.java:
/**
* Gets the file format's file extensions.
*
* @return An unmodifiable list of file extension strings, e.g. "text".
*/
public List<String> getFileExtensions() {
return Collections.unmodifiableList(mimeTypes);
}

[SES-508] Handle security restrictions for applet sandboxes properly

Fri, 26 Sep 2008 11:34:49 +0200 (CEST)

The RepositoryConnectionBase class (and possibly others) try to read the system property "org.openrdf.repository.debug" which causes a SecurityException when trying to initialize an HTTPRepository. This prevents the HTTP Repository API to be used within applets.

The commons-logging API version 1.1 also had a similar problem, see http://www.mail-archive.com/commons-user@jakarta.apache.org/msg15932.html

The solution is to catch and ignore security exceptions.

[SES-538] Exception when specified dir is actually a file

Thu, 8 May 2008 11:27:56 +0200 (CEST)

I think this is a bug in Console.java...

------------------
$ touch /tmp/is-a-file
$ mkdir /tmp/is-a-dir
$ start-console.sh

> connect /tmp/is-a-dir.
Disconnecting from default data directory
Connected to /tmp/is-a-dir

> connect /tmp/not-existing.
ERROR: Specified path is not an (existing) directory: /tmp/not-existing

> connect /tmp/is-a-file.
ERROR: Failed to initialize data file /tmp/is-a-file/repositories/SYSTEM/memorystore.data
31-Mar-2008 02:53:49 org.openrdf.console.Console installNewManager
SEVERE: Failed to install new manager
org.openrdf.repository.RepositoryException: Failed to initialize data file /tmp/is-a-file/repositories/SYSTEM/memorystore.data
        at org.openrdf.repository.sail.SailRepository.initialize(SailRepository.java:85)
        at org.openrdf.repository.base.RepositoryWrapper.initialize(RepositoryWrapper.java:60)
        at org.openrdf.repository.event.base.NotifyingRepositoryWrapper.initialize(NotifyingRepositoryWrapper.java:130)
        at org.openrdf.repository.manager.SystemRepository.initialize(SystemRepository.java:70)
...etc

----------------
502 : akam 3695 private boolean connectLocal(String path) {
503 : akam 3197 File dir = new File(path);
504 : if (!dir.exists() && !dir.isDirectory()) {
505 : writeError("Specified path is not an (existing) directory: " + path);
506 : return false;
507 : }
508 :
509 : return installNewManager(new LocalRepositoryManager(dir), dir.toString());
510 : jeen 2729 }

It looks like the && above should be || ?
Thanks, Jon

[SES-541] Externally set bindings are erroneously included in query result

Thu, 8 May 2008 11:28:01 +0200 (CEST)

Variable bindings that are set using the setBinding(...) methods on org.openrdf.query.Query objects are erroneously included in the query result. For example, with the following code...

TupleQuery query = con.prepareTupleQuery(QueryLanguage.SERQL, "select Entity FROM {Entity} rdf:type {Class}");
query.setBinding("Class", RDFS.CLASS);
TupleQueryResult queryResult = query.evaluate();

...the "Class" binding is include in each BindingSet returned by the TupleQueryResult. One would expect that the returned BindingSet's would only include bindings for the "Entity" variable.

[SES-540] RemoteRepositoryManager doesn't extract repository URI info from repository info list

Thu, 8 May 2008 11:28:06 +0200 (CEST)

RemoteRepositoryManager fails to extract repository URIs from repository overviews returned by a Sesame server. The manager treats the value as a Literal and tries to extract it's label, where the value is actually a URI. As a result of this, RepositoryInfo objects returned by this manager do not have their 'location' set. The location is not used in Sesame internally, so Sesame itself is not affected.

[SES-548] Test RDFStoreTest.testGetContextIDs() doesnt commit or rollback at end

Mon, 30 Jun 2008 17:36:52 +0200 (CEST)

The JUnit test:
RDFStoreTest.testGetContextIDs()

ends with:
  con.addStatement(picasso, paints, guernica, context2);
  assertEquals(1, countElements(con.getContextIDs()));
  assertEquals(context2, first(con.getContextIDs()));
}

should be:
  con.addStatement(picasso, paints, guernica, context2);
  assertEquals(1, countElements(con.getContextIDs()));
  assertEquals(context2, first(con.getContextIDs()));
  con.commit();
}

[SES-552] SPARQL parser fails with IllegalArgumentException when invalid URIs are encountered

Mon, 30 Jun 2008 17:36:47 +0200 (CEST)

The SPARQL query parser doesn't handle invalid (relative) URIs properly. The following two queries both fail with an IllegalArgumentException, where this should have been a MalformedQueryException:

SELECT *
WHERE {
?s <abc> ?o
}

SELECT *
WHERE {
?s ?p "abc"^^<abc>
}

[SES-555] Sesame server reinitializes all repositories when a single repository configuration is changed

Mon, 30 Jun 2008 17:36:58 +0200 (CEST)

LocalRepositoryManager, which is used by the Sesame server to manage its repositories, currently shuts down and reinitializes all repositories when the system confiuration is updated. This needs to be improved so that only the repositories whose configuration has actually changed are reinitialized.

[SES-562] Sesame server fails to start when it is not allowed to read env vars

Fri, 26 Sep 2008 11:31:28 +0200 (CEST)

On start-up, the Sesame server tries to determine what platform it is running on (unix, windows, etc.) to find the directory that is normally used for application data. The class info.aduna.platform.PlatformFactory also tries to determine which window manager is used in case a unix/linux OS is detected. It does this by reading a number of environment variables. However, when the webapp containiner (e.g. Tomcat) enforces some security restrictions that do no allow webapps to read these vars, a java.security.AccessControlException is thrown. These exceptions need to be handled properly.

[SES-575] NativeStore potentially uses wrong triple index for statement patterns with specified object

Fri, 26 Sep 2008 11:31:34 +0200 (CEST)

Given an index other than spoc, the computation of the score for a pattern with object != NativeValue.UNKNOWN_ID and context == NativeValue.UNKNOWN_ID is computed incorrectly.

In TripleStore$TripleIndex.getPatternScore(int s, int p, int o, int c), the case block for object ('o') is missing a break. When the 'o' field of the index specification string is reached, and if object is != NativeValue.UNKNOWN_ID, then the score is incremented and the context block is entered. If context is == NativeValue.UNKNOWN_ID, computation ends here, though a char other than 'c' might be the next one in the array. This is not what you would expect.

Simply add the break.

[SES-600] Duplicate constraints generated for DESCRIBE queries

Fri, 26 Sep 2008 11:34:54 +0200 (CEST)

The SPARQL parser generates query models with duplicate value constraints when parsing DESCRIBE queries. This adds some (but probably minimal) unnecessary query evaluation overhead.

[SES-639] Rollback on MemoryStore starts statement clean-up process when there's nothing to clean up

Wed, 17 Dec 2008 14:04:45 +0100 (CET)

MemoryStoreConnection.rollback() currently always triggers the clean-up process, even if there's nothing to be cleaned up. This causes an unnecessary iteration over all statements that holds an exclusive write lock, blocking any other requests.

[SES-636] Connection registration in SailBase is not properly synchronized

Duplicate — Wed, 17 Dec 2008 14:04:55 +0100 (CET)

The org.openrdf.sail.helpers.SailBase, a common superclass of the memory, native and rdbms store, does not register its connections properly. Connection removal from the registration map is properly synchronized, but additions are not. In highly concurrent environments, this leads to warnings of the form: "tried to remove unknown connection object from store".

[SES-539] XML Literal normalization

Related — Mon, 31 Oct 2011 15:54:52 +0100 (CET)

XML literal normalization is not implemented yet.

[SES-679] RDF/XML parser fails on relative URIs in rdf:datatype

Related — Tue, 13 Mar 2012 15:21:48 +0100 (CET)

Trying to parse the following document:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://example.com/#">
  <Foo>
    <bar rdf:datatype="hello">Zyzzyx</bar>
  </Foo>
</rdf:RDF>

I get:

org.openrdf.rio.RDFParseException: Not a valid (absolute) URI: hello [line 3, column 37]

The problem is the value "hello" for rdf:datatype, Rio expects an absolute URI. Section 2.14 of the RDF/XML spec says however that rdf:datatype can contain relative URIs which are to be resolved in the usual way.

[SES-991] clear command does not clear namespaces

Wed, 9 May 2012 06:03:46 +0200 (CEST)

clear command does not clear namespaces

[SES-537] Sesame server doesn't properly shut down repositories

Thu, 8 May 2008 11:27:52 +0200 (CEST)

Issue reported here: http://www.openrdf.org/forum/mvnforum/viewthread?thread=1636

Hi,
are the shutdown()'s methods of the repositories are really invoked when the openrdf-sesame web-app is being closed within Tomcat? (Sesame2.0 official release - Tomcat/5.0.28)

I've debuged this and shutdown() methods of neither - our owlim or sesame's memory store are invoked when the web-app is closed.

Is it a bug or there is some prerequisite/requrement/interface/etc. that the sail should implement in order to be shutdown properly?

[SES-542] Upload after clear results in duplicate namespace declarations

Fri, 26 Sep 2008 11:35:15 +0200 (CEST)

I am using a native store with two indexes and adding data to two different contexts. Whenever I clear the repository (via http using a command console) and then re-upload the data, I suddenly get duplicate entries in the set of namespace declarations (when I request a list of namespace, I get, for example, the dc: namespace twice, both with identical prefix and namespace name).

[SES-546] Workbench Should Be Able to read Local Repositories

Fri, 26 Sep 2008 11:35:09 +0200 (CEST)

The workbench can be a great way to visualize the repository, but since the workbench currently cannot open local repositories (or create repositories) it has limited use and cannot be recommended as a general purpose tool.

[SES-551] OutOfMemory Exception When Objects Are Queued For Finalization

Related — Fri, 26 Sep 2008 11:35:46 +0200 (CEST)

We have one non-inferencing model which has 200,000 triples and we also have 200 inferencing models and number of statements every inferencing model stores is about 1000 (excluding the statements that inferencing itself creates). All models are stored in memory.

In our code, we open a connection, get statements from the model and close the connection and we do this for at least one million time in a very short time. Our problem is that we're getting an OutOfMemory Exception even though we have a pretty good server (details below). We used a memory profiler to figure out what is going on and we noticed that there are so many objects sitting in the memory to be finalized and they don't go away until full gc performs. After full gc, we continue and keep getting statements from our model and number of objects in the memory goes up again. You'll see the list of objects below;

CclassName ---------------------------------------------------------------------- numObjectsPendingFinalization
java.lang.ref.Finalizer
info.aduna.concurrent.locks.WritePrefReadWriteLockManager$1 ---- 2,819,785
org.openrdf.sail.helpers.SailBaseIteration ------------------------------------- 1,871,071
info.aduna.concurrent.locks.ReadPrefReadWriteLockManager$1 ----- 1,894,609
info.aduna.concurrent.locks.ExclusiveLockManager$1 ----------------------- 943,632
org.openrdf.repository.sail.SailRepositoryConnection ------------------------ 569,166
info.aduna.concurrent.locks.WritePrefReadWriteLockManager$2 ------- 555,563
org.apache.commons.dbcp.cpdsadapter.ConnectionImpl ------------------- 15,384
[number of objects goes down significantly at this point]

Server Details:
64Bit Server
java version "1.5.0_15" 64-Bit Server VM
Number of CPUs: 4 Dual Core 2Ghz
Total Memory Size: 4Gb
Size of Memory used by JVM: 3Gb

This may not be the real cause but when I was looking for the reason for OutOfMemory Excpetion, I found this article. The following paragraph is from http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/gbywc.html#gbyvh:

One other potential source of OutOfMemoryError arises with applications that make excessive use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. Instead, after garbage collection the objects are queued for finalization, which occurs at a later time. In the Sun implementation, finalizers are executed by a daemon thread that services the finalization queue. If the finalizer thread cannot keep up with the finalization queue, then the Java heap could fill up and OutOfMemoryError would be thrown. One scenario that can cause this situation is when an application creates high-priority threads that cause the finalization queue to increase at a rate that is faster than the rate at which the finalizer thread is servicing that queue.

[SES-561] MemoryStore fails with java.io.UTFDataFormatException when trying to persist really long literals

Duplicate — Fri, 26 Sep 2008 11:36:06 +0200 (CEST)

When loading RDF statements (in my case from an TriG file) into a MemorySail using a filebackend, it throws the following exception when flushing a large literal to the file:
java.io.UTFDataFormatException: encoded string too long: 73108 bytes
        java.io.DataOutputStream.writeUTF(DataOutputStream.java:347)
        java.io.DataOutputStream.writeUTF(DataOutputStream.java:306)
        org.openrdf.sail.memory.FileIO.writeValue(FileIO.java:258)
        org.openrdf.sail.memory.FileIO.writeStatements(FileIO.java:200)
        org.openrdf.sail.memory.FileIO.write(FileIO.java:87)
        org.openrdf.sail.memory.MemoryStore.sync(MemoryStore.java:823)
        org.openrdf.sail.memory.MemoryStore.scheduleSyncTask(MemoryStore.java:755)
        org.openrdf.sail.memory.MemoryStore.commit(MemoryStore.java:709)
        org.openrdf.sail.memory.MemoryStoreConnection.commitInternal(MemoryStoreConnection.java:305)
        org.openrdf.sail.helpers.SailConnectionBase.commit(SailConnectionBase.java:250)
        org.openrdf.repository.sail.SailRepositoryConnection.commit(SailRepositoryConnection.java:79)
        org.openrdf.repository.base.RepositoryConnectionBase.setAutoCommit(RepositoryConnectionBase.java:194)
        org.openrdf.repository.base.RepositoryConnectionBase.addInputStreamOrReader(RepositoryConnectionBase.java:328)
        org.openrdf.repository.base.RepositoryConnectionBase.add(RepositoryConnectionBase.java:253)
        de.l3s.evaluation.rdfstores.sesame2.Sesame2.load(Sesame2.java:180)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:225)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:199)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:161)
        de.l3s.evaluation.RDFStoreEvaluation.main(RDFStoreEvaluation.java:92)
this exception occurs using openrdf-sesame-2.0.1-onejar.jar. When updating to 2.1.2, the following exception is thrown by the same code in the same environment:
org.openrdf.repository.RepositoryException: org.openrdf.sail.SailException: java.io.UTFDataFormatException: encoded string too long: 73108 bytes
        org.openrdf.repository.sail.SailRepositoryConnection.commit(SailRepositoryConnection.java:82)
        org.openrdf.repository.base.RepositoryConnectionBase.setAutoCommit(RepositoryConnectionBase.java:194)
        org.openrdf.repository.base.RepositoryConnectionBase.addInputStreamOrReader(RepositoryConnectionBase.java:328)
        org.openrdf.repository.base.RepositoryConnectionBase.add(RepositoryConnectionBase.java:253)
        de.l3s.evaluation.rdfstores.sesame2.Sesame2.load(Sesame2.java:180)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:225)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:199)
        de.l3s.evaluation.RDFStoreEvaluation.evaluate(RDFStoreEvaluation.java:161)
        de.l3s.evaluation.RDFStoreEvaluation.main(RDFStoreEvaluation.java:92)

[SES-563] Different order of patterns in query lead to different result sets

Mon, 30 Jun 2008 17:39:12 +0200 (CEST)

When the order of the patterns of a query is changed, the result set changes as well. In the following case, it happens when a mandatory pattern is stated after an optional pattern. This should not happen, since the order of the patterns does not have any impact on the meaning of a graph pattern. Specifically, the following two SPARQL queries lead to different result sets. From the first to the second query, the first pattern is moved to the third position (behind the first optional pattern).

They should run on any RDF data, but they were only tested on the RDF data below:

SPARQL query 1:

SELECT DISTINCT
?p ?d ?r ?l ?c
WHERE {
?s1 ?p ?s2 .
?s1 rdf:type ?d .
OPTIONAL { ?s2 rdf:type ?r } .
OPTIONAL { ?p rdfs:label ?l . FILTER isLiteral(?l) } .
OPTIONAL { ?p rdfs:comment ?c . FILTER isLiteral(?c) }
}

SPARQL query 2:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT DISTINCT
?p ?d ?r ?l ?c
WHERE {
?s1 rdf:type ?d .
OPTIONAL { ?s2 rdf:type ?r } .
?s1 ?p ?s2 .
OPTIONAL { ?p rdfs:label ?l . FILTER isLiteral(?l) } .
OPTIONAL { ?p rdfs:comment ?c . FILTER isLiteral(?c) }
}

This was tested on this RDF graph:
<uri:one> <uri:property1> <uri:two> .
<uri:one> <uri:property1> <uri:three> .
<uri:one> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <uri:class1> .
<uri:one> <uri:property2> "literal one"^^<http://www.w3.org/2001/XMLSchema#String> .
<uri:two> <uri:property3> "literal two" .
<uri:two> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <uri:class2> .
<uri:three> <uri:property3> "literal three" .
<uri:three> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <uri:class2> .

The result set of the first query is:
d c r p l
d=uri:class1 null r=uri:class2 p=uri:property1 null
d=uri:class1 null null p=http://www.w3.org/1999/02/22-rdf-syntax-ns#type null
d=uri:class1 null null p=uri:property2 null
d=uri:class2 null null p=http://www.w3.org/1999/02/22-rdf-syntax-ns#type null
d=uri:class2 null null p=uri:property3 null

The result set of the second query is:
d c r p l
d=uri:class1 null r=uri:class2 p=uri:property1 null

[SES-623] Query algebra objects do not clone their internal collections correctly

Wed, 22 Oct 2008 20:45:22 +0200 (CEST)

Lists and sets that are used by query model objects are not cloned correctly by their clone() method. The cloned objects refer to the list/set objects of the cloned object.

[SES-630] Incorrect query result ordering when optional statement pattern variables are involved

Wed, 17 Dec 2008 14:05:32 +0100 (CET)

We observed some strange behavior on a sparql query involving 'order by' over a variable which is used in a OPTIONAL statement pattern - in such case the result is not ordered.

The query is:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?a ?label
WHERE {
   ?a rdf:type <http://www.w3.org/2002/07/owl#Thing> .
   OPTIONAL {?a rdfs:label ?label }
}
ORDER BY ?label

the sample data :
<?xml version="1.0"?>
<rdf:RDF
  xmlns="http://TestSort#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xmlns:owl="http://www.w3.org/2002/07/owl#"
xml:base="http://TestSort">
<owl:Ontology rdf:about="">
  <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Created with TopBraid Composer</owl:versionInfo>
</owl:Ontology>
<owl:Thing rdf:ID="Thing_1"/>
<owl:Thing rdf:ID="Thing_3"/>
<owl:Thing rdf:ID="Thing_5"/>
<owl:Thing rdf:ID="Thing_0">
  <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thing_6</rdfs:label>
</owl:Thing>
<owl:Thing rdf:ID="Thing_7"/>
<owl:Thing rdf:ID="Thing_2">
  <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thing_2</rdfs:label>
</owl:Thing>
<owl:Thing rdf:ID="Thing_4">
  <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Thing_4</rdfs:label>
</owl:Thing>
</rdf:RDF>

and the output:
http://TestSort#Thing_1
http://TestSort#Thing_3
http://TestSort#Thing_5
http://TestSort#Thing_0 "Thing_6"^^http://www.w3.org/2001/XMLSchema#string
http://TestSort#Thing_7
http://TestSort#Thing_2 "Thing_2"^^http://www.w3.org/2001/XMLSchema#string
http://TestSort#Thing_4 "Thing_4"^^http://www.w3.org/2001/XMLSchema#string