You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by th...@apache.org on 2021/10/06 16:08:28 UTC
svn commit: r1893939 -
/jackrabbit/site/live/oak/docs/features/observation.html
Author: thomasm
Date: Wed Oct 6 16:08:27 2021
New Revision: 1893939
URL: http://svn.apache.org/viewvc?rev=1893939&view=rev
Log:
OAK-936: Site checkin for project Oak Documentation-1.41-SNAPSHOT
Modified:
jackrabbit/site/live/oak/docs/features/observation.html
Modified: jackrabbit/site/live/oak/docs/features/observation.html
URL: http://svn.apache.org/viewvc/jackrabbit/site/live/oak/docs/features/observation.html?rev=1893939&r1=1893938&r2=1893939&view=diff
==============================================================================
--- jackrabbit/site/live/oak/docs/features/observation.html (original)
+++ jackrabbit/site/live/oak/docs/features/observation.html Wed Oct 6 16:08:27 2021
@@ -292,6 +292,22 @@
</ul>
<div class="section">
<div class="section">
+<h3><a name="Reliable_Event_Processing"></a>Reliable Event Processing</h3>
+<p>JCR event listeners might miss some events because:</p>
+<ul>
+
+<li>Event listeners only see events that occurred after they are installed. Earlier events are missed (e.g., events via migration).</li>
+<li>In case of power failure (or similar) right after an event was persisted, but before the event listener was able to process it.</li>
+</ul>
+<p>To process events reliably, efficiently, and with low latency, consider using a hybrid approach:</p>
+<ul>
+
+<li>At startup, use a query to process old events (that were missed so far).</li>
+<li>Use an event listener to process recent events with low latency.</li>
+</ul>
+<p>For example, to reliably process changes to nodes, one might create an ordered index on the <tt>jcr:lastModified</tt> property of these nodes. (This assumes this property is updated when needed.) At startup of the application, an event listener is registered, so that subsequent events are processed with low latency. To process events that happened <i>before</i> the listener was registered (e.g. via migration, or in case of a crash), run a query to check for <tt>jcr:lastModified >= $lastProcessed</tt> where <tt>$lastProcessed</tt> is the time when the last events were processed via event listener. This timestamp needs to be persisted from time to time (consider persisting it with a delay of for example one minute, to avoid too frequent updates).</p>
+<p>This way, one can be sure all events are processed.</p></div>
+<div class="section">
<h3><a name="OakEventFilter"></a>OakEventFilter</h3>
<p><tt>@since Oak 1.6</tt></p>
<p>To make use of new filtering capability use following approach</p>
@@ -309,28 +325,28 @@ EventListener listener = ...
ObservationManager om = session.getWorkspace().getObservationManager();
-//Cast to JackrabbitObservationManager
+// Cast to JackrabbitObservationManager
JackrabbitObservationManager jrom = (JackrabbitObservationManager) om;
-//Construct a JackrabbitEventFilter
+// Construct a JackrabbitEventFilter
JackrabbitEventFilter jrFilter = new JackrabbitEventFilter();
-//Wrap it as OakEventFilter
+// Wrap it as OakEventFilter
OakEventFilter oakFilter = FilterFactory.wrap(jrFilter);
oakFilter.withIncludeSubtreeOnRemove();
-//Set other filtering criteria
+
+// Set other filtering criteria
+// ...
jrom.addEventListener(listener, oakFilter);
</pre></div></div>
<p>Refer to <a class="externalLink" href="https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/jcr/observation/filter/OakEventFilter.html">OakEventFilter</a> javadocs for more details on what filtering criteria are supported</p></div>
<div class="section">
-<h3><a name="Benefits_of_Filter_approach"></a>Benefits of Filter approach</h3>
+<h3><a name="Benefits_of_Filter_Approach"></a>Benefits of Filter Approach</h3>
<p>In Jackrabbit Oak JCR <tt>EventListener</tt> are implemented as Oak <a class="externalLink" href="https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/commit/Observer.html">Observer</a> which are backed by an in memory queue. Upon any save call done at JCR layer NodeStore in Oak pushes repository root node in this queue which is later used to compute diff from older root and then generate the JCR Events.</p>
-<p>For events to work properly it needs to be ensure that this in memory queue does not get filled up. Having a precise filter helps Oak in <i>prefiltering</i> changes before they are added to queue. For e.g. if filter stats that its only interested in changes under ‘/content’ then Oak can check if changes under that path have happened for given change, if not then such a change is not queued.</p></div>
-<div class="section">
-<h3><a name="Observation_queue_overflow"></a>Observation queue overflow</h3></div></div>
+<p>For events to work properly it needs to be ensure that this in memory queue does not get filled up. Having a precise filter helps Oak in <i>prefiltering</i> changes before they are added to queue. For e.g. if filter stats that its only interested in changes under ‘/content’ then Oak can check if changes under that path have happened for given change, if not then such a change is not queued.</p></div></div>
</div>
</div>
</div>