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 #133 (Closed): Sporadic concurrent access in StringPoolSessionhttps://code.mulgara.org/issues/1332008-07-24T07:27:07Zronald -ronald@foo.bar
<p>Twice, on two different machines/os's/jdk's we've seen the<br />ItqlInterpreterBeanUnitTest fail with the following stack trace:<br /><pre>
org.mulgara.query.QueryException: Unable to load file:/Users/pag/src/mulgara/trunk/data/camera.n3 into rmi://10.0.1.198/server1#itqlmodel
at org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:726)
at org.mulgara.resolver.DatabaseSession.setModel(DatabaseSession.java:562)
at org.mulgara.server.rmi.SessionWrapperRemoteSession.setModel(SessionWrapperRemoteSession.java:123)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:637)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at org.mulgara.server.rmi.RemoteSessionImpl_Stub.setModel(Unknown Source)
at org.mulgara.server.rmi.RemoteSessionWrapperSession.setModel(RemoteSessionWrapperSession.java:166)
at org.mulgara.query.operation.Load.doTx(Load.java:101)
at org.mulgara.query.operation.DataInputTx.sendMarshalledData(DataInputTx.java:111)
at org.mulgara.query.operation.Load.execute(Load.java:79)
at org.mulgara.itql.ItqlInterpreterBean.load(ItqlInterpreterBean.java:707)
at org.mulgara.itql.ItqlInterpreterBeanUnitTest.testLoadApi8(ItqlInterpreterBeanUnitTest.java:577)
Caused by: org.mulgara.query.QueryException: org.mulgara.query.MulgaraTransactionException: Transaction rollback triggered
at org.mulgara.resolver.MulgaraInternalTransaction.implicitRollback(MulgaraInternalTransaction.java:516)
at org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:627)
at org.mulgara.resolver.DatabaseSession.execute(DatabaseSession.java:723)
at org.mulgara.resolver.DatabaseSession.setModel(DatabaseSession.java:562)
at org.mulgara.server.rmi.SessionWrapperRemoteSession.setModel(SessionWrapperRemoteSession.java:123)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.mulgara.query.QueryException: org.mulgara.resolver.spi.ResolverException: Unable to read input statements
at org.mulgara.resolver.store.StatementStoreResolver.modifyModel(StatementStoreResolver.java:381)
at org.mulgara.resolver.InternalResolver.modifyModel(InternalResolver.java:164)
at org.mulgara.resolver.SetModelOperation.execute(SetModelOperation.java:153)
at org.mulgara.resolver.MulgaraInternalTransaction.execute(MulgaraInternalTransaction.java:623)
Caused by: org.mulgara.query.QueryException: org.mulgara.query.TuplesException: Exception while reading file:/Users/pag/src/mulgara/trunk/data/camera.n3
at org.mulgara.content.n3.Parser.checkForException(Parser.java:517)
at org.mulgara.content.n3.Parser.getTriple(Parser.java:539)
at org.mulgara.content.n3.N3Statements.next(N3Statements.java:389)
at org.mulgara.resolver.store.StatementStoreResolver.modifyModel(StatementStoreResolver.java:353)
Caused by: java.lang.IllegalStateException: Concurrent Access of [[StringPoolSession]] Attempted
at org.mulgara.resolver.StringPoolSession.checkCurrentThread(StringPoolSession.java:787)
at org.mulgara.resolver.StringPoolSession.localizePersistent(StringPoolSession.java:207)
at org.mulgara.resolver.store.StatementStoreResolver.localizePersistent(StatementStoreResolver.java:451)
at org.mulgara.resolver.PersistentResolverSession.localize(PersistentResolverSession.java:97)
at org.mulgara.content.n3.Parser.createBlankNode(Parser.java:453)
at org.mulgara.content.n3.Parser.getBlankNode(Parser.java:424)
at org.mulgara.content.n3.Parser.toNode(Parser.java:362)
at org.mulgara.content.n3.Parser.quad(Parser.java:272)
at com.hp.hpl.jena.n3.N3AntlrParser.emitQuad(N3AntlrParser.java:66)
at com.hp.hpl.jena.n3.N3AntlrParser.objectList(N3AntlrParser.java:738)
at com.hp.hpl.jena.n3.N3AntlrParser.propValue(N3AntlrParser.java:622)
at com.hp.hpl.jena.n3.N3AntlrParser.propertyList(N3AntlrParser.java:336)
at com.hp.hpl.jena.n3.N3AntlrParser.statement0(N3AntlrParser.java:287)
at com.hp.hpl.jena.n3.N3AntlrParser.statement(N3AntlrParser.java:204)
at com.hp.hpl.jena.n3.N3AntlrParser.document(N3AntlrParser.java:153)
at com.hp.hpl.jena.n3.N3Parser.parse(N3Parser.java:61)
at org.mulgara.content.n3.Parser.run(Parser.java:213)
</pre></p>
<p>Unfortunately, this has not been reproduceable. But interestingly<br />enough the stack trace was identical in both cases.</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 #122 (Closed): Support XAResource.setTransactionTimeouthttps://code.mulgara.org/issues/1222008-05-19T00:38:16Zronald -ronald@foo.bar
<p><code>MulgaraXAResource</code> currently ignores the timeout and returns false. Instead<br />it should set the underlying transaction timeout.</p>
<p>This depends on <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> for complete functionality.</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 - Bug #70 (Closed): Using a database-session in multiple threads can deadlock the serverhttps://code.mulgara.org/issues/702007-09-11T10:56:51Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">We have a shutdown handler on the client that closes open sessions;
<span class="nt"><br/></span>
however, this shutdown handler is run is separate thread of its own.
<span class="nt"><br/></span>
So an abort of the client while it's doing a db operation can generate
<span class="nt"><br/></span>
the following sequence of events which leads to a deadlock:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1 Thread-2
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>set autocommit off
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>...
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>insert ... close()
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
(i.e. the insert and the close happen almost simultaneously). The
<span class="nt"><br/></span>
resulting stack traces are roughly:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-1:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.insert()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>DatabaseSession.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaxction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.deactivate() <span class="ni">&lt;</span>---- monitor held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.commitTransation()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.transacactionComplete()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Thread-2:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>DatabaseSession.close()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.rollbackCurrentTransactions()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransactionManager.acquireMutex() <span class="ni">&lt;</span>--- mutex held
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.execute()
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>MulgaraTransaction.activate() <span class="ni">&lt;</span>--- blocked
<span class="nt"><br/></span>
{noformat}
<span class="nt"><br/></span>
<span class="nt"><br/></span>
</code></pre> Mulgara - Bug #48 (Closed): update results incorrect when autocommit on and multiple sessions are...https://code.mulgara.org/issues/482007-02-28T04:02:05Zronald -ronald@foo.bar
<pre>
<code class="html syntaxhl">The following sequence illustrates the problem:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>In first db session:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'hi' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'bye' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>delete select $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>insert <span class="ni">&lt;</span>a:foo<span class="ni">&gt;</span> <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> 'blah' into <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;</span>Then in second db session:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>select $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o from <span class="ni">&lt;</span><span class="nt"><a</span> <span class="na">href=</span><span class="s">"local:///topazproject#foo"</span><span class="nt">></span>local:///topazproject#foo<span class="nt"></a></span><span class="ni">&gt;</span> where $s <span class="ni">&lt;</span>a:bar<span class="ni">&gt;</span> $o ;
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The final select should return a single result:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>blah<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
but really returns
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>blah<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>hi<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;&nbsp;</span>a:foo a:bar <span class="ni">&quot;</span>bye<span class="ni">&quot;</span>
<span class="nt"><br/></span>
<span class="nt"><br/></span>
If the 'delete select' or the last 'insert' is followed by a 'set
<span class="nt"><br/></span>
autocommit on' then the result is correct. Also, if the query is done
<span class="nt"><br/></span>
in the same db session then the result is correct.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I'm attaching two patches. The first actually does three things:
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it adds a log message when the [[TransactionalAnswer]] is cloned so
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>that all instance creations are logged (this bug was leading to
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>'TransactionalAnswer not closed' warnings for these cloned
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>instances)
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it makes sure the query answer in a 'delete select' or 'insert
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>select' is properly closed.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
<span class="ni">&nbsp;</span>- it makes sure the query answers are properly closed in
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>RelationalResolution - I noticed these while searching the code
<span class="nt"><br/></span>
<span class="ni">&nbsp;&nbsp;&nbsp;</span>for other [[LocalizedTuples]] usage after finding the above problem.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
The second patch is a test case for this problem: it fails with stock
<span class="nt"><br/></span>
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>, but that succeeds with the first patch applied.
<span class="nt"><br/></span>
<span class="nt"><br/></span>
I'm not 100% convinced that the first patch is the true solution, but
<span class="nt"><br/></span>
it does fix numerous 'TransactionalAnswer not closed' warnings and
<span class="nt"><br/></span>
does seem to work. I.e. I think it should probably be applied, but
<span class="nt"><br/></span>
something else is probably also needed.
<span class="nt"><br/></span>
</code></pre> 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>