Mulgara Project: Issueshttps://code.mulgara.org/https://code.mulgara.org/favicon.ico?15861924492008-10-23T13:56:58ZMulgara Project
Redmine Mulgara - Feature #163 (New): Improve performance of distributed resolverhttps://code.mulgara.org/issues/1632008-10-23T13:56:58Zronald -ronald@foo.bar
<p>Right now the distributed resolver seems somewhat overly slow. The<br />queries take quite some time, as well as there being a long (100ms on<br />my machine) unexplained pause between prepare and commit.</p> Mulgara - Bug #162 (New): Transactions involving transactional resolvers do not have snapshot iso...https://code.mulgara.org/issues/1622008-10-23T13:40:30Zronald -ronald@foo.bar
<p>See <a class="external" href="http://www.topazproject.org/trac/ticket/1036">http://www.topazproject.org/trac/ticket/1036</a> for the scenario. Because<br />resolvers are enlisted lazily, mulgara suffers from the same problem. But<br />attempting to always enlist all resolvers at the beginning of every transaction<br />may be quite expensive, and is also in the case of the distributed resolver<br />nearly impossible.</p>
<p>We may want to add a flag so users can choose whether they want this or not.</p> Mulgara - Feature #161 (New): Support recovery in distributed resolver's MultiXAResourcehttps://code.mulgara.org/issues/1612008-10-23T13:35:25Zronald -ronald@foo.bar
<p>Transactions are currently not remembered across restarts. We could possibly<br />store transactions and their states locally in a graph.</p> Mulgara - Feature #160 (Closed): Cache lucene indexeshttps://code.mulgara.org/issues/1602008-10-23T13:22:20Zronald -ronald@foo.bar
<p>The lucene indexes in the [<a class="source" href="https://code.mulgara.org/projects/mulgara/repository/3/entry/trunk/src/jar/resolver-lucene">source:trunk/src/jar/resolver-lucene</a>/ lucene resolver]<br />are created anew for each transaction; this is fairly costly. We should cached them<br />across transactions, re-opening them if a modification occurred since the last time<br />they were checked out.</p> Mulgara - Feature #158 (Closed): Cache index readers and writers in !LuceneResolverhttps://code.mulgara.org/issues/1582008-10-19T10:14:54Zronald -ronald@foo.bar
<p>New lucene index readers and writers are currently created for every<br />transaction. This is costly, so we should provide a pool of index readers<br />and writers, and re-open the readers at the start of a transaction if<br />anything has been written since they were last (re-)opened.</p> Mulgara - Bug #123 (Closed): Detect deceased rmi clients and clean uphttps://code.mulgara.org/issues/1232008-05-19T00:46:11Zronald -ronald@foo.bar
<p>If an rmi client goes away (exits, is killed, whatever) while holding<br />the write lock then mulgara will stay locked up forever. One of the<br />rmi wrapper classes needs to implement <code>java.rmi.Unreferenced</code> to get<br />notified when clients disappear and needs to abort that client's<br />transaction, if any.</p>
<p>See also <a class="external" href="http://java.sun.com/j2se/1.5.0/docs/guide/rmi/faq.html#leases2">http://java.sun.com/j2se/1.5.0/docs/guide/rmi/faq.html#leases2</a> .</p>
<p>Note that <a class="issue tracker-9 status-27 priority-27 priority-high3 closed" title="Feature: Abort idle transactions on timeout (Closed)" href="https://code.mulgara.org/issues/121">#121</a> will help here, but catching the unreferenced<br />notifications has the potential to clean things up much quicker<br />because in a typical production internal network environment the rmi<br />lease timeouts can be set much lower than the transaction timeout.</p> Mulgara - Feature #121 (Closed): Abort idle transactions on timeouthttps://code.mulgara.org/issues/1212008-05-19T00:33:42Zronald -ronald@foo.bar
<p>If a client goes away while holding the write lock, the write lock is<br />never released, leading to mulgara being locked forever. Currently the<br />timeout "only" sets the timeout on the internal transaction manager<br />which just causes the transaction to be marked for rollback on a<br />timeout. However, setting the timeout should also start a timer which<br />is used to abort a non-active transaction (this should happened for<br />both read-write as well as read-only transactions as the latter could<br />be holding on to a phase, leading to a "memory leak").</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 - Feature #47 (Closed): (Patch) query speed improvement by 30% - 40%https://code.mulgara.org/issues/472007-02-26T12:31:17Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">Creating exceptions (instances of Throwable) is an expensive
<span class="nt"><br/></span>
operation, mostly because of the stack trace. However, browsing the
<span class="nt"><br/></span>
code I've seen a number of places where 'new Throwable()' was used
<span class="nt"><br/></span>
unconditionally. Therefore I ran some experiments.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Setup: a db with 1.4 million triples (production data), and 200
<span class="nt"><br/></span>
<span class="ni">&quot;</span>production<span class="ni">&quot;</span> queries (most of them unique). Each test was run by
<span class="nt"><br/></span>
starting mulgara, running the first 100 queries, then timing the
<span class="nt"><br/></span>
second 100 queries, and finally shutting mulgara down again. The
<span class="nt"><br/></span>
log level was WARN, so that normally nothing gets printed. No
<span class="nt"><br/></span>
explicit transactions were used (i.e. autoCommit=true).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Some queries were simple (on the order of 50 ms or less to answer),
<span class="nt"><br/></span>
some more complex (close to a second); the client was using SOAP to
<span class="nt"><br/></span>
access the db, which introduces typically between 40 and 100 ms
<span class="nt"><br/></span>
overhead per query, so these results are <span class="ni">&quot;</span>worst case<span class="ni">&quot;</span>, i.e. the
<span class="nt"><br/></span>
speed-up noted is probably slightly higher using RMI.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Three sets of tests were run: straight rev <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/192"</span><span class="nt">></span>192<span class="nt"></a></span> (<span class="ni">&quot;</span>with stack traces<span class="ni">&quot;</span>),
<span class="nt"><br/></span>
a version with all 'new Throwable()' removed (<span class="ni">&quot;</span>without stack traces<span class="ni">&quot;</span>),
<span class="nt"><br/></span>
and a version with various 'new Throwable()' surounded by appropriate
<span class="nt"><br/></span>
conditions (<span class="ni">&quot;</span>partial stack traces<span class="ni">&quot;</span>); the patch for this last set is
<span class="nt"><br/></span>
the one attached to this issue.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Each test was run with 1, 2, and 3 client threads hitting the db.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Here are the results (the alignment of the table will probably be
<span class="nt"><br/></span>
messed up in the html):
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>stack-traces threads times (sec) avg min avg% min%
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>with 1 29.2 31.4 29.0 29.9 29.0 100 100
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>with 2 18.7 19.5 18.1 18.8 18.1 100 100
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>with 3 17.7 17.6 19.2 18.2 17.6 100 100
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>without 1 17.7 17.7 18.1 17.8 17.7 60 61
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>without 2 13.0 12.5 13.1 12.9 12.5 69 69
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>without 3 12.6 12.2 12.5 12.4 12.2 68 69
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>partial 1 18.0 18.6 18.0 18.2 18.0 61 62
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>partial 2 12.5 12.9 13.3 12.9 12.5 69 69
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>partial 3 12.8 11.2 13.1 12.4 11.2 68 64
<span class="nt"><br/></span>
<span class="nt"><br/></span>
As you can see, the <span class="ni">&quot;</span>partial<span class="ni">&quot;</span> (which is the attached patch) gives
<span class="nt"><br/></span>
around 30% - 40% reduction in query time.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The attached patch is quite simple and quite safe. In a couple
<span class="nt"><br/></span>
cases it makes the Throwable instantiation conditional on the log
<span class="nt"><br/></span>
level at which it will get printed, and in the other two cases it
<span class="nt"><br/></span>
removes unnecessary (i.e. duplicate) stack-trace creation. In
<span class="nt"><br/></span>
short it does not remove any information from the logs.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
No tests are affected by this patch.
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #45 (Closed): doclet error during javadoc buildhttps://code.mulgara.org/issues/452007-02-25T11:19:55Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">While building the javadocs, the following error occurs a couple times:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>[javadoc] Building tree for all the packages and classes...
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>[javadoc] java.lang.IllegalArgumentException: Illegal group reference
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>[javadoc] at java.util.regex.Matcher.appendReplacement(Matcher.java:713)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>[javadoc] at org.mulgara.doclet.RCSTaglet.replaceRcsKeywords(RCSTaglet.java:198)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>[javadoc] at org.mulgara.doclet.RCSTaglet.toString(RCSTaglet.java:128)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The problem is that any $ needs to be escaped in the replacement string.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
A simple patch for this is attached.
</code></pre> Mulgara - Bug #44 (Closed): Error during transaction.commit() causes infinite recursion and loopinghttps://code.mulgara.org/issues/442007-02-25T09:13:24Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">This is svn head (rev <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/189"</span><span class="nt">></span>189<span class="nt"></a></span>), i.e. with the new transaction code.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
Here's a small snippet of the stack when the error is triggered:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.objectweb.jotm.TransactionImpl.commit(TransactionImpl.java:222)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.terminateTransaction(MulgaraTransaction.java:330)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.deactivate(MulgaraTransaction.java:154)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>at org.mulgara.resolver.MulgaraTransaction.execute(MulgaraTransaction.java:207)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If commit() throws an exception, implicitRollback() will be invoked at
<span class="nt"><br/></span>
line 333, which in turn call checkActivated() on line 262, which in
<span class="nt"><br/></span>
turn calls implicitRollback() on line 442 because inuse is 0 (from
<span class="nt"><br/></span>
deactivate()).
<span class="nt"><br/></span>
<span class="nt"><br/></span>
At this point things go horribly wrong...
<span class="nt"><br/></span>
<span class="nt"><br/></span>
An easy way to trigger this is run out of disk space where the db
<span class="nt"><br/></span>
resides (e.g. on linux create a fs on a small file and mount using the
<span class="nt"><br/></span>
loop device: 'dd if=/dev/zero of=/tmp/mdb bs=4096 count=1000',
<span class="nt"><br/></span>
'mke2fs /tmp/mdb', 'mount -o loop /tmp/mdb /mnt/disk').
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Feature #39 (Closed): Don't throw away underlying exception when xml-literal validation...https://code.mulgara.org/issues/392006-12-13T01:54:55Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">When validating an XML-Literal the exception from a failed validation is thrown away.
<span class="nt"><br/></span>
This makes is harder to figure out what's going (we were seeing spurious failures
<span class="nt"><br/></span>
that couldn't be reproduced given the logged literal string).
</code></pre> Mulgara - Bug #36 (Closed): Basic query failurehttps://code.mulgara.org/issues/362006-11-20T23:50:01Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following setup demonstrates the problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test&gt;;"</span><span class="nt">></span>local:///topazproject#test<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) or (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s $p $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#test"</span><span class="nt">></span>local:///topazproject#test<span class="nt"></a></span><span class="ni">&gt;</span> where (
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>$s $p $o
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>or ($s $impliedBy $o and $impliedBy <span class="ni">&lt;</span>topaz:implies<span class="ni">&gt;</span> $p)
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>) and ($s <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:bar<span class="ni">&gt;</span>);
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The two queries are logically equivalent (the <span class="ni">&lt;</span>mulgara:is<span class="ni">&gt;</span> term is duplicated in the first query, and factored out in the second query). However, while the first query returns three statements, the second query only returns one. Specifically, the first query returns
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>bar:get<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
but the second returns only
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&lt;</span>foo:bar<span class="ni">&gt;</span> <span class="ni">&lt;</span>foo:set<span class="ni">&gt;</span> <span class="ni">&lt;</span>user:joe<span class="ni">&gt;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #33 (Closed): can create same model twice with different typeshttps://code.mulgara.org/issues/332006-11-13T06:59:54Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following is accepted by mulgara:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>create <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span><span class="ni">&gt;</span> <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/mulgara#XMLSchemaModel&gt;;"</span><span class="nt">></span>http://mulgara.org/mulgara#XMLSchemaModel<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
This then results in a partially unusable database, as this
<span class="nt"><br/></span>
error cannot be corrected anymore. E.g.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>drop <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1&gt;;"</span><span class="nt">></span>local:///foo#m1<span class="ni">&amp;</span>gt;;<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
produces the error
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Error resolving [$s $p $o $_from] from <span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///foo#m1"</span><span class="nt">></span>local:///foo#m1<span class="nt"></a></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Model 287 has more than one type!
<span class="nt"><br/></span>
<span class="nt"><br/></span>
It would be more robust if the 'create' checked that the model type
<span class="nt"><br/></span>
is the same in the case where the model already exists.
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #29 (Closed): Apply old memory leak patchhttps://code.mulgara.org/issues/292006-10-28T06:08:06Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The Fedora folks found and a fixed a memory leak in Kowari 1.0.5. It
<span class="nt"><br/></span>
looks like this patch is still needed. See also
<span class="nt"><br/></span>
[<span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://prototypo.blogspot.com/2005/09/kowari-memory-leak-found-and-fixed.html"</span><span class="nt">></span>http://prototypo.blogspot.com/2005/09/kowari-memory-leak-found-and-fixed.html<span class="nt"></a></span>]
<span class="nt"><br/></span>
Here is the one-line patch against Mulgara svn head:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
-----------------------------------------------------------------
<span class="nt"><br/></span>
Index: src/jar/util-xa/java/org/mulgara/store/xa/FreeList.java
<span class="nt"><br/></span>
===================================================================
<span class="nt"><br/></span>
--- src/jar/util-xa/java/org/mulgara/store/xa/FreeList.java (revision <span class="nt"><a</span> <span class="na">href=</span><span class="s">"http://mulgara.org/trac/changeset/106"</span><span class="nt">></span>106<span class="nt"></a></span>)
<span class="nt"><br/></span>
+++ src/jar/util-xa/java/org/mulgara/store/xa/FreeList.java (working copy)
<span class="nt"><br/></span>
@@ -1070,6 +1070,7 @@
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>public Phase() throws IOException {
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>synchronized (FreeList.this) {
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>if (currentPhase != null) {
<span class="nt"><br/></span>
+ removeClosedPhases();
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>sequenceNumber = currentPhase.sequenceNumber + 1;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>head = currentPhase.head;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>tail = currentPhase.tail;
<span class="nt"><br/></span>
-----------------------------------------------------------------
<span class="nt"><br/></span>
</code></pre>