Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-07-29T20:48:41ZMulgara Project
Redmine Mulgara - Bug #135 (New): Mulgara keeps file lock if parsing of RDF/XML failshttps://code.mulgara.org/issues/1352008-07-29T20:48:41ZAlex Hall -alexhall@revelytix.com
<p>Running Mulgara 2.0.0 on Windows XP, if the parsing of an RDF/XML file fails due to illegal content during a load, Mulgara does not release the lock on that file.</p> Mulgara - Bug #134 (New): Jar files contain duplicateshttps://code.mulgara.org/issues/1342008-07-24T22:17:10ZPaula Gearon
<p>There are multiple occurrences of several files in the distribution jars. For instance, grepping for the Castor generated file Jetty:<br /><pre>
$ jar tf mulgara-2.0.0.jar | grep 'Jetty\.class'
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
org/mulgara/config/Jetty.class
</pre></p>
<p>The final jars are built out of several sub-jars, which is where the duplicates come from. These duplicates need to be removed.</p> Mulgara - Bug #132 (New): GraphAnswer improperly builthttps://code.mulgara.org/issues/1322008-07-10T00:54:09ZPaula Gearon
<p>This class was built as a result type for CONSTRUCT queries, as per <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: CONSTRUCT SPARQL queries (Closed)" href="https://code.mulgara.org/issues/112">#112</a>. As DESCRIBE queries also return graphs, the initial implementation is also used as the result type for these queries as well.</p>
<p>Unfortunately, when I first built CONSTRUCT I was half thinking of how they are used in TQL INSERT/SELECT queries, where a multiple of 3 selection items are automatically inserted into the correct column. This translated into the GraphAnswer object accepting only 3 columns of results, and renaming these to "subject", "predicate" and "object". This is incorrect, as it prevents templates from having more than 3 columns (they must be a multiple of 3), prevents sorting by selected variables, and disallows different variable names. These are all incorrect.</p>
<p>CONSTRUCT queries are converted to SELECT queries with a multiple of 3 columns. The appropriate Answer will still have only 3 columns, which may be renamed to "subject", "predicate", and "object", but it must wrap this wider Answer, and not a 3 column Answer as is currently presumed.</p>
<p>The implementation will keep an internal counter for iterating over groups of 3 columns in the wrapped Answer with each call to <code>next()</code>. This continues until the end of a row. At the end of a row, the counter resets to zero, and the wrapped Answer has next() called on it. If this <em>wrapping</em> Answer is applied late enough, then sorting will be handled automatically.</p>
<p>DESCRIBE queries need not change from their current implementation, but if this happens then sorting will not be applied. Given that DESCRIBE has no requirements on returned data, this may be acceptable. However, there is an alternative.</p>
<p>Like CONSTRUCT queries, DESCRIBE can have their own Answer type that wraps a given Answer. In this case, we can presume DESCRIBE queries to return multiple columns, with the first 2 given the labels of "predicate" and "object". All other columns will be mapped to "subject". The implementation will need to scan each of these columns to find that <em>one</em> column that is bound for that row, and return that as the subject. Again, this will provide sorting, if the wrapper is applied late enough.</p>
<p>Both types of Answer will appear to have only 3 Variables: "subject", "predicate" and "object". Many of the filtering characteristics will also be the same, in that Subjects cannot be a Literal, and Predicate cannot be a Literal nor a Blank Node. For this reason, GraphAnswer should be changed to an abstract class implementing this functionality, with the implementations of <code>next()</code> and <code>getObject()</code> performed in the extending classes.</p> Mulgara - Bug #108 (New): Triggering constraints in Krulehttps://code.mulgara.org/issues/1082008-05-17T21:55:23ZPaula Gearon
<p>When Krule runs a rule, it triggers other rules that it affects the underlying constraints for. These triggered rules test if they should run by comparing the size of their resolution to the last time they were run, and proceeding if that size has changed.</p>
<p>This needs to become a 2 stage process. Rules should trigger constraints, and constraints should run the above test. If the size of a constraint resolution changes, then it triggers the rule that it belongs to.</p> Mulgara - Bug #96 (New): Machine names do not always allow model creationhttps://code.mulgara.org/issues/962008-04-04T06:14:12ZPaula Gearon
<p>The server in this scenario was running with the following names:<br />[Gonzo.local, localhost, 127.0.0.1, 10.0.1.2]</p>
<p>Selecting from a remote client using RMI graph names was successful:<br /><pre>
select $s $p $o from <rmi://Gonzo.local/server1#>;
[ rmi://10.0.1.2/server1#, http:www.w3.org/1999/02/22-rdf-syntax-ns#type, http://mulgara.org/mulgara#Model ]
1 rows returned
</pre></p>
<p>However, creating a graph using this host name failed:<br /><pre>
create <rmi://gonzo.local/server1#data>
Error: Could not commit creation of model rmi://gonzo.local/server1#data of type http://mulgara.org/mulgara#Model
</pre></p>
<p>Was the problem due to the upper case "G"?<br /><pre>
create <rmi://gonzo.local/server1#data>
Error: Could not commit creation of model rmi://Gonzo.local/server1#data of type http://mulgara.org/mulgara#Model
</pre></p>
<p>But using the IP works:<br /><pre>
create <rmi://10.0.1.2/server1#data>
Successfully created graph rmi://10.0.1.2/server1#data
</pre></p>
<p>(Also note the inconsistent use of "graph" and "model". This should be addressed)</p> Mulgara - Bug #95 (New): Remote backups not compressedhttps://code.mulgara.org/issues/952008-04-03T22:40:17ZPaula Gearon
<p>When calling remote backup on a graph on a server (meaning the server saves the file to the local filesystem) the backup file is not compressed if the backup file ends in .gz. This contradicts remote load, which will try to decompress files that end in .gz.</p>
<p>Local load and graph backup are always uncompressed, regardless of filename.</p> Mulgara - Bug #83 (Feedback): Mulgara fails to start after abrupt terminationhttps://code.mulgara.org/issues/832008-03-07T06:07:03Zronald -ronald@foo.bar
<p>I killed mulgara abruptly, and subsequently it failed to start.<br />According to Andrae's initial analysis, the problem is that mulgara<br />assumes during recovery that certain deleted structures are internally<br />valid when in this case they aren't.</p>
<p>Attached is the db from after the crash. The failure to recover seems to<br />be reproducable only on 32-bit jvm's, and even then not consistently<br />(due to the timing between certain operations).</p> Mulgara - Bug #82 (In Progress): Read-close-write creates redundant phasehttps://code.mulgara.org/issues/822008-03-05T21:13:22ZPaula Gearon
<p>When reading and closing an Answer in a write transaction, a redundant micro-commit occurs. This leads to unbounded growth when regularly reading in large transactions.</p> Mulgara - Bug #81 (In Progress): Blank Node Assignment in Inserts inconsistent with autocommithttps://code.mulgara.org/issues/812008-02-28T06:23:04ZAndrae Muys -andrae@netymon.com
<p>It appears that the binding of variables to blank nodes when inserting <br />statements behaves differently depending on whether autocommit is turned <br />on for the session. If I have autocommit turned on and execute the <br />following iTQL commands:<br /><pre>
create <rmi://localhost/server1#test>;
insert <test:subj> <test:pred> $x $x <test:value> 'o1'
into <rmi://localhost/server1#test> ;
insert <test:subj> <test:pred> $x $x <test:value> 'o2'
into <rmi://localhost/server1#test> ;
select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
</pre><br />Then I see that the variable "x" is bound to different blank nodes in <br />each of the two insertions, and the resulting model has 4 statements. <br />This is the behavior (behaviour?) that I would expect.</p>
<p>However, when I turn autocommit off prior to the first insertion, and <br />turn it back on after the second insertion, then I see that the variable <br />"x" is bound to the <strong>same</strong> blank node in each of the insertions, <br />resulting in 3 total statements in the model, which came as a bit of a <br />surprise to me. Is this the expected behavior in that situation?</p> Mulgara - Bug #56 (Feedback): Distributed blank nodes not uniquely identifiedhttps://code.mulgara.org/issues/562007-04-15T05:55:17ZPaula Gearon
<pre>
<code class="html syntaxhl">Any blank nodes returned from a distributed resolver may contain the same gnode IDs as local blank nodes. This means they cannot be distinguished. Add a factory in the appropriate place to mark blank nodes from elsewhere with the IP of their source.
</code></pre> Mulgara - Bug #53 (New): FileSystemResolver keeps exhausting heaphttps://code.mulgara.org/issues/532007-03-20T03:51:53ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">Regularly seeing heap exhaustion when running the [[FileSystemResolver]] unit test.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I believe this resolver is memory bound and needs to be modified to use disk-backed structures.
</code></pre> Mulgara - Bug #52 (New): Insufficient dereferencing in TransactionalAnswer.sessionClose leading t...https://code.mulgara.org/issues/522007-03-19T07:03:14ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">There is a need for the normal error-path to properly dereference and cleanup transactions so that exceptional failures within the error-path can be logged without being lost in 'noise'.
</code></pre> Mulgara - Bug #31 (New): resolveVariableModel does not check securityAdaptorListhttps://code.mulgara.org/issues/312006-11-10T07:01:02ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">This allows queries containing variable models to bypass the security layer.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Mulgara currently doesn't have any security modules in its distribution - so this code path is currently only used by various unit-tests. This bug must be fixed when we come to implement security modules.
</code></pre> Mulgara - Bug #15 (In Progress): Product of Sum form has very poor performance.https://code.mulgara.org/issues/152006-09-06T04:30:23ZAndrae Muys -andrae@netymon.com
<pre>
<code class="html syntaxhl">[[OrderedAppend]] currently assumes that all it's operands share a common ordering. This is currently guarenteed by [[TuplesOperations]].append(), but the use of calls to project() on all operands not matching the first's variable list. This has signifigant performance ramifications as the desired ordering is unknown until any parent-join is optimised.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Without the projections currently done by [[TuplesOperations]].append(), we need new logic in [[OrderedAppend]] to handle mapping variables to operands columns. This is not a problem unless there the disjunction is subject to a join containing a left-bound prefix including mismatched variables.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Consider the following tuple expressions:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
A[$z] ^ B( C[$z $y] v D[$y $z] )
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>A[] will provide $z prefix to B[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>B[] currently passes this on blindly to C[] and D[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>This will bind $z for $y in D[], leading to an incorrect result.
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Currently the non-union compatible
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Fixing this will require either reordering D[], or filtering it; deciding between them is a performance optimisation issue.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
A[$y $z] ^ B(C[$y] v D[$z])
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Note:
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Here there is a full prefix provided by A[] to B[].
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>The prefix needs to be decomposed for C[] and D[]
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>This is a case of non-union compatible disjunction, and will probably result in UNBOUND's.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Cases where this is probably a problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
non-symmetric sum-of-products (ie. {$a <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $b ^ $b <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $c in <span class="ni">&lt;</span>m1<span class="ni">&gt;</span>} v {$b <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $c ^ $a <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $b in <span class="ni">&lt;</span>m2<span class="ni">&gt;</span>} )
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Note: this is one of the key areas of concern. Differences between models can cause join-optimisation to generate a different ordering; This interferes with attempts to improve SOP performance which is required to support efficient views.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
symmetric disjunctions: (ie. $s <span class="ni">&lt;</span>foo<span class="ni">&gt;</span> $o v $o <span class="ni">&lt;</span>bar<span class="ni">&gt;</span> $s). - uncommon.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
non-union compatible disjunction (ie. $s <span class="ni">&lt;</span>name<span class="ni">&gt;</span> $name v $s <span class="ni">&lt;</span>email<span class="ni">&gt;</span> $email)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Note: this query is better phrased as a subquery anyway.
</code></pre> Mulgara - Bug #8 (New): Temp directory managementhttps://code.mulgara.org/issues/82006-07-11T13:50:53Zbrian -brian@foo.bar
<pre>
<code class="html syntaxhl">A research group has reported seeing Kowari fill up temp directories and fall over. This was on Solaris, but it might be a more general problem to solve. Nothing to reproduce it yet, but I just wanted to capture the experience to potentially investigate this issue moving forward.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The usage pattern was one big load and then mostly queries with the occasional insert.
</code></pre>