Author: buildbot
Date: Thu Jun 4 19:50:14 2015
New Revision: 953826
Log:
Staging update by buildbot for sling
Modified:
websites/staging/sling/trunk/content/ (props changed)
websites/staging/sling/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.html
Propchange: websites/staging/sling/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Jun 4 19:50:14 2015
@@ -1 +1 @@
-1683511
+1683618
Modified:
websites/staging/sling/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.html
==============================================================================
---
websites/staging/sling/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.html
(original)
+++
websites/staging/sling/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.html
Thu Jun 4 19:50:14 2015
@@ -222,9 +222,11 @@
<h3 id="basic-principles">Basic Principles</h3>
<p>The foundation of the distributed event mechanism is to distribute each
event to every node in a clustered environment. The event distribution
mechanism has no knowledge about the intent of the event and therefore is not
able to make delivery decisions by itself. It is up to the sender to decide
what should happen. The sender must explicitly declare an event to be
distributed as for example framework related events (bundle stopped, installed
etc.) should not be distributed.</p>
<p>The event mechanism will provide additional functionality making it easier
for event receivers to decide if they should process an event. The event
receiver can determine if the event is a local event or comming from a remote
application node. Therefore a general rule of thumb is to process events only
if they're local and just regard remote events as a FYI.</p>
-<p>For distributed events two properties are defined (check the
<em>EventUtil</em> class):
-<em> </em>event.distribute<em> - this flag is set by the sender of an event to
give a hint if the event should be distributed across instances. For example
JCR observation based events are already distributed on all instances, so there
is no further need to distribute them. If the flag is present, the event will
be distributed. The value has currently no meaning, however the EventUtil
method should be used to add this property. If the flag is absent the event is
distributed locally only.
-</em> <em>event.application</em> - An identifier for the current application
node in the cluster. This information will be used to detect if an event has
been created on different nodes. If the event has been created on the same
node, the <em>event.application</em> is missing, if it is a remote event, the
<em>event.application</em> contains the ID of the node, the event has been
initially created. Use the <em>EventUtil.isLocal(Event)</em> method to detect
if the event is a local or a distributed event.</p>
+<p>For distributed events two properties are defined (check the
<em>EventUtil</em> class):</p>
+<ul>
+<li><em>event.distribute</em> - this flag is set by the sender of an event to
give a hint if the event should be distributed across instances. For example
JCR observation based events are already distributed on all instances, so there
is no further need to distribute them. If the flag is present, the event will
be distributed. The value has currently no meaning, however the EventUtil
method should be used to add this property. If the flag is absent the event is
distributed locally only.</li>
+<li><em>event.application</em> - An identifier for the current application
node in the cluster. This information will be used to detect if an event has
been created on different nodes. If the event has been created on the same
node, the <em>event.application</em> is missing, if it is a remote event, the
<em>event.application</em> contains the ID of the node, the event has been
initially created. Use the <em>EventUtil.isLocal(Event)</em> method to detect
if the event is a local or a distributed event.</li>
+</ul>
<p>While the <em>event.distribute</em> must be set by the sender of an event
(if the event should be distributed), the <em>event.application</em> property
is maintained by the event mechanism. Therefore a client sending an event
should <em>never</em> set this information by itself. This will confuse the
local event handlers and result in unexpected behaviour. On remote events the
<em>event.application</em> is set by the event distribution mechanism.</p>
<h3 id="event-distribution-across-application-nodes-cluster">Event
Distribution Across Application Nodes (Cluster)</h3>
<p>The (local) event admin is the service distributing events locally. The
Sling Distributing Event Handler is a registered event handler that is
listening for events to be distributed. It distributes the events to remote
application notes, Sling's resource tree is used for distribution. The
distributing event handler writes the events into the resource tree, the
distributing event handlers on other application nodes get notified through
observation and then distribute the read events locally.</p>
@@ -232,7 +234,7 @@
<h2 id="sending-scheduled-events">Sending Scheduled Events</h2>
<p>Scheduled events are OSGi events that have been created by the environemnt.
They are generated on each application node of the cluster through an own
scheduler instance. Sending these events works the same as sending events based
on JCR events (see above).</p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%;
text-align: right;">
- Rev. 1679505 by cziegeler on Fri, 15 May 2015 07:06:36 +0000
+ Rev. 1683618 by sseifert on Thu, 4 Jun 2015 19:50:02 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache
Sling project
