svn commit: r912990 - in /websites/staging/jena/trunk/content: ./ documentation/tdb/faqs.html

[bu...@apache.org]

Author: buildbot
Date: Thu Jun 19 07:59:49 2014
New Revision: 912990

Log:
Staging update by buildbot for jena

Modified:
    websites/staging/jena/trunk/content/   (props changed)
    websites/staging/jena/trunk/content/documentation/tdb/faqs.html

Propchange: websites/staging/jena/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jun 19 07:59:49 2014
@@ -1 +1 @@
-1603742
+1603746

Modified: websites/staging/jena/trunk/content/documentation/tdb/faqs.html
==============================================================================
--- websites/staging/jena/trunk/content/documentation/tdb/faqs.html (original)
+++ websites/staging/jena/trunk/content/documentation/tdb/faqs.html Thu Jun 19 07:59:49 2014
@@ -150,6 +150,7 @@
 <li><a href="#transactions">Does TDB support Transactions?</a></li>
 <li><a href="#multi-jvm">Can I share a TDB dataset between multiple applications?</a></li>
 <li><a href="#impossibly-large-object">What is the "Impossibly Large Object" exception?</a></li>
+<li><a href="#fusek-tdb-memory-leak">Does Fuseki/TDB have a memory leak?</a></li>
 </ul>
 <p><a name="transactions"></a></p>
 <h2 id="does-tdb-support-transactions">Does TDB support transactions?</h2>
@@ -177,14 +178,29 @@ applications portable to another SPARQL 
 <h2 id="what-is-the-impossibly-large-object-exception">What is the "Impossibly Large Object" exception?</h2>
 <p>The "Impossibly Large Object" exception is an exception that occurs when part of your TDB dataset has become corrupted.  It may
 only affect a small section of your dataset so may only occur intermittently depending on your queries.  A query that touches
-the entirety of the dataset e.g.</p>
+the entirety of the dataset will always experience this exception e.g.</p>
 <div class="codehilite"><pre><span class="n">SELECT</span> <span class="o">*</span> <span class="n">WHERE</span> <span class="p">{</span> <span class="p">{</span> ?<span class="n">s</span> ?<span class="n">p</span> ?<span class="n">o</span> <span class="p">}</span> <span class="n">UNION</span> <span class="p">{</span> <span class="n">GRAPH</span> ?<span class="n">g</span> <span class="p">{</span> ?<span class="n">s</span> ?<span class="n">p</span> ?<span class="n">o</span> <span class="p">}</span> <span class="p">}</span> <span class="p">}</span>
 </pre></div>
 
 
-<p>Will always experience this exception.  The corruption may have happened at any time in the past and once it has happened there
+<p>The corruption may have happened at any time in the past and once it has happened there
 is no way to repair it.  Corrupted datasets will need to be rebuilt from the original source data, this is why we <strong>strongly</strong>
 recommend you use <a href="tdb_transactions.html">transactions</a> since this protects your dataset against corruption.</p>
+<p><a name="fuseki-tdb-memory-leak"></a></p>
+<h2 id="does-fusekitdb-have-a-memory-leak">Does Fuseki/TDB have a memory leak?</h2>
+<p>A number of users have reported a suspected memory leak when using Fuseki/TDB when it used to serve a database that has continuous high
+load with a mixture of queries and updates.  Having investigate the problem this is not a memory leak per-se rather a limitation of how
+<a href="tdb_transactions.html">transactions</a> are implemented for TDB.</p>
+<p>TDB uses write-ahead logging so new data is written both to an on-disk journal and kept in-memory.  This is necessary because TDB permits
+a single writer and multiple readers at any one time and readers are guaranteed to always see the state of the database at the time they
+started reading.  Therefore until there are no active readers it is not possible to update the database directly since readers are actively
+accessing it hence why a journal is used.  The in-memory journal holds some memory that cannot be freed up until such time as the database
+has no active readers/writers and the changes it holds can be safely flushed to disk.</p>
+<p>This means that in scenarios where there is continuous high load on the system TDB never reaches a state where it is able to flush the journal
+eventually causing out of memory errors in Fuseki.  You can see if you are experiencing this issue by examining your database directory, if it
+contains a <code>.jrnl</code> file that is non-empty then Fuseki/TDB is having to hold the journal in-memory.</p>
+<p><strong>However</strong> because this relates to transactional use and the journal is also stored on disk no data will be lost, by stopping and restarting 
+Fuseki the journal will be flushed to disk.</p>
   </div>
 </div>