incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Sling Website > Apache Sling Eventing and Job Handling
Date Tue, 19 Oct 2010 14:24:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1810/9/1/_/styles/combined.css?spaceKey=SLINGxSITE&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/Apache+Sling+Eventing+and+Job+Handling">Apache
Sling Eventing and Job Handling</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~justinedelson">Justin
Edelson</a>
    </h4>
        <br/>
                         <h4>Changes (1)</h4>
                                 
    
<div id="page-diffs">
            <table class="diff" cellpadding="0" cellspacing="0">
            <tr><td class="diff-snipped" >...<br></td></tr>
            <tr><td class="diff-unchanged" >For distributed events two properties
are defined (check the _EventUtil_ class): <br>* _event.distribute_ - 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. <br></td></tr>
            <tr><td class="diff-changed-lines" >* _event.application_ - 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 <span
class="diff-changed-words">no<span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">t</span><span
class="diff-added-chars"style="background-color: #dfd;">d</span>e,</span> the
_event.application_ is missing, if it is a remote event, the _event.application_ contains
the ID of the node, the event has been initially created. Use the _EventUtil.isLocal(Event)_
method to detect if the event is a local or a distributed event. <br></td></tr>
            <tr><td class="diff-unchanged" > <br>While the _event.distribute_
must be set by the sender of an event (if the event should be distributed), the _event.application_
property is maintained by the event mechanism. Therefore a client sending an event should
*never* set this information by itself. This will confuse the local event handlers and result
in unexpected behaviour. On remote events the _event.application_ is set by the event distribution
mechanism. <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
        </table>
</div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <p><b>NOTE: This documentation is work in progress!</b></p>

<h2><a name="ApacheSlingEventingandJobHandling-Overview"></a>Overview</h2>

<p>The Apache Sling Event Support bundle provides interesting services for advanced
event handling and job processing. While this bundle leverages the OSGi EventAdmin, it provides
a very powerful support for so called jobs: a job is a task which has to be performed by a
component - the Sling job handling ensures that exactly one component performs this task.</p>

<p>To get some hands on code, you can refer to the following tutorials:</p>
<ul>
	<li><a href="/confluence/display/SLINGxSITE/How+to+Manage+Events+in+Sling" title="How
to Manage Events in Sling">How to Manage Events in Sling</a></li>
	<li><a href="/confluence/display/SLINGxSITE/Scheduler+Service+%28commons+scheduler%29"
title="Scheduler Service (commons scheduler)">Scheduler Service &#40;commons scheduler&#41;</a></li>
</ul>


<p>The Sling Event Supports adds the following services:</p>
<ul>
	<li><a href="#ApacheSlingEventingandJobHandling-jobs">Jobs</a></li>
	<li><a href="#ApacheSlingEventingandJobHandling-distributed">Distributed Events</a></li>
	<li><a href="#ApacheSlingEventingandJobHandling-timed">Scheduled Events</a></li>
</ul>


<p><a name="ApacheSlingEventingandJobHandling-jobs"></a></p>
<h2><a name="ApacheSlingEventingandJobHandling-Jobs%28GuaranteeofProcessing%29"></a>Jobs
(Guarantee of Processing)</h2>

<p>In general, the eventing mechanism (OSGi EventAdmin) has no knowledge about the contents
of an event. Therefore, it can't decide if an event is important and should be processed by
someone. As the event mechanism is a "fire event and forget about it" algorithm, there is
no way for an event admin to tell if someone has really processed the event. Processing of
an event could fail, the server or bundle could be stopped etc.</p>

<p>On the other hand, there are use cases where the guarantee of processing a job is
a must and usually this comes with the requirement of processing this job exactly once. Typical
examples are sending notification emails (or sms) or post processing of content (like thumbnail
generation of images or documents).</p>

<p>The Sling Event Support adds the notion of a job to the OSGi EventAdmin. A job is
a special OSGi event that someone has to process (do the job). The job event has a special
topic <em>org/apache/sling/event/job</em> to indicate that the event contains
a job. These job events are consumed by the Sling Job Handler - it ensures that someone does
the job! To support different jobs and different processors of such jobs, the real topic of
the event is stored in the <em>event.job.topic</em> property of the original event.
When a job event (event with the topic <em>org/apache/sling/event/job</em>) is
received, a new event with the topic from the property <em>event.job.topic</em>
is fired (Firing this event comes of course with a set of rules and constraints explained
below).</p>

<p>In order to distinguish a job which occured twice and a job which is generated "at
the same time" on several nodes, each job can be uniquely identified by its topic (property
<em>event.job.topic</em>) and an optional job name, the <em>event.job.id</em>
property. It is up to the client creating the event to ensure that the <em>event.job.id</em>
property is unqiue <b>and</b> identical on all application nodes. If the job name
is not provided for the job, then it is up to the client to ensure that the job event is only
fired once. Usually for jobs generated based on user interaction, a unique job name is not
required as the job is only created through the user interaction.</p>

<h3><a name="ApacheSlingEventingandJobHandling-JobProcessors"></a>Job Processors</h3>

<p>A job processor is a service consuming and processing a job. It listens for OSGi
events with the job topic. The OSGi EventAdmin usually comes with a timeout for event handlers.
An event handler must consume an OSGi event as fast as possible otherwise the handler might
get a timeout and get blacklisted. Therefore a job processor should never directly process
the job in the event handler method, but do this async.</p>

<p>In addition the Sling Job Handler needs to get notified if someone is processing
a job and when someone has finished processing this job.</p>

<p>To make implementing such a job processor easier, there is the <em>JobUtil</em>
utility class along with the <em>JobProcessor</em> interface. The <em>JobUtil</em>
class has a helper method for this: <em>processJob(Event, JobProcessor)</em>.
The job processor must implement the <em>JobProcessor</em> interface which consists
of a single <em>process(Event)</em> method. When the event handler receives a
job event through the OSGi EventAdmin, it calls <em>JobUtil.processJob(event, this)</em>
and returns. This utility method takes care to notify the Sling Job Handler that someone is
processing the job. Then the <em>process(Event)</em> method of the job processor
is called in the background and when it returns, the Sling Job Handler is notified that the
job is completed (or processing failed).</p>

<p>If the job processor wants to do the background processing by itself or does not
need background processing at all, it must signal starting and completition of the job by
call <em>JobUtil.acknowledgeJob(Event), _JobUtil.finishedJob(event)</em> or _JobUtil.rescheduleJob(Event).</p>

<h3><a name="ApacheSlingEventingandJobHandling-ProcessingofJobs"></a>Processing
of Jobs</h3>

<p>Incoming jobs are first persisted in the repository (for failover etc.) and then
a job is put into a processing queue. There are different types of queues defining how the
jobs are processed (one after the other, in parallel etc.).</p>

<p>For managing queues, the Sling Job Handler uses the OSGi ConfigAdmin - it is possible
to configure one or more queue configurations through the ConfigAdmin. One way of creating
and configuring such configurations is the Apache Felix WebConsole.</p>

<h4><a name="ApacheSlingEventingandJobHandling-QueueConfigurations"></a>Queue
Configurations</h4>

<p>A queue configuration can have the following properties:</p>

<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <b>Property Name</b>     </td>
<td class='confluenceTd'> <b>Description</b> </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.name</em>       </td>
<td class='confluenceTd'> The name of the queue. If matching is used for topics, the
value {0} can be used for replacing the matched part. </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.type</em>       </td>
<td class='confluenceTd'> The type of the queue: ORDERED, UNORDERED, TOPIC_ROUND_ROBIN,
IGNORE, DROP </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.topics</em>       </td>
<td class='confluenceTd'> A list of topics processed by this queue. Either the concrete
topic is specified or the topic string ends with /* or /. If a star is at the end all topics
and sub topics match, with a dot only direct sub topics match. </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.maxparallel</em>       </td>
<td class='confluenceTd'> How many jobs can be processed in parallel? -1 for number
of processors.</td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.retries</em>       </td>
<td class='confluenceTd'> How often should the job be retried. -1 for endless retries.
</td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.retrydelay</em>       </td>
<td class='confluenceTd'> The waiting time in milliseconds between job retries. </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.priority</em>       </td>
<td class='confluenceTd'> The thread priority: NORM, MIN, or MAX </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.runlocal</em>       </td>
<td class='confluenceTd'> Should the jobs only be processed on the cluster node they
have been created? </td>
</tr>
<tr>
<td class='confluenceTd'> <em>queue.applicationids</em>       </td>
<td class='confluenceTd'> Optional list of application (cluster node) ids. If configured,
these jobs are only processed on this application node.</td>
</tr>
<tr>
<td class='confluenceTd'> <em>service.ranking</em> </td>
<td class='confluenceTd'> A ranking for this configuration.</td>
</tr>
</tbody></table>
</div>


<p>The configurations are processed in order of their service ranking. The first matching
queue configuration is used for the job.</p>

<h4><a name="ApacheSlingEventingandJobHandling-OrderedQueues"></a>Ordered
Queues</h4>

<p>An ordered queue processes one job after the other.</p>

<h4><a name="ApacheSlingEventingandJobHandling-UnorderedQueues"></a>Unordered
Queues</h4>

<p>Unordered queues process jobs in parallel.</p>

<h4><a name="ApacheSlingEventingandJobHandling-TopicRoundRobinQueues"></a>Topic-Round-Robin
Queues</h4>

<p>The jobs are processed in parallel. Scheduling of the jobs is based on the topic
of the jobs. These are started by doing round-robin on the available topics.</p>

<h4><a name="ApacheSlingEventingandJobHandling-IgnoringQueues"></a>Ignoring
Queues</h4>

<p>A queue of type <em>ignoring</em> ignores this job. The job is persisted
but not processed. This can be used to delay processing of some jobs. With a changed configuration
and a restart of the Sling Job Handler the ignored jobs can be processed at a later time.</p>

<h4><a name="ApacheSlingEventingandJobHandling-DroppingQueues"></a>Dropping
Queues</h4>

<p>A queue of type <em>drop</em> is dropping a job - which means it is not
processed at all and directly discarded.</p>


<h3><a name="ApacheSlingEventingandJobHandling-Persistence"></a>Persistence</h3>

<p>The job event handler listens for all job events (all events with the topic <em>org/apache/sling/event/job</em>)
and will as a first step persist those events in the JCR repository. All job events are stored
in a tree under the job root node <em>/var/eventing/jobs</em>. Persisting the
job ensures proper handling in a clustered environment and allows failover handling after
a bundle stop or server restart. Once a job has been processed by someone, the job will be
removed from the repository.</p>

<p>When the job event listener tries to write a job into the repository it will check
if the repository already contains a job with the given topic <em>event.job.topic</em>
and job name (property <em>event.job.id</em>). If the event has already been written
by some other application node, it's not written again.</p>

<p>Each job is stored as a separate node with the following properties:</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <b>Property Name</b>     </td>
<td class='confluenceTd'> <b>Description</b> </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:topic</em>       </td>
<td class='confluenceTd'> The topic of the job </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:id</em>          </td>
<td class='confluenceTd'> The unique identifier of this job (optional).</td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:created</em>     </td>
<td class='confluenceTd'> The date and time when the event has been created (stored
in the repository)</td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:application</em> </td>
<td class='confluenceTd'> The identifier of the node where the job was created </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:properties</em>  </td>
<td class='confluenceTd'> Serialized properties </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:finished</em>    </td>
<td class='confluenceTd'> The date and time when the job has been finished </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:processor</em>   </td>
<td class='confluenceTd'> The identifier of the node which processed the job (after
successful processing) </td>
</tr>
</tbody></table>
</div>


<p>The failover of an application node is accomplished by locking. If a job is locked
in the repository a session scoped lock is used. If this application node dies, the lock dies
as well. Each application node observes the JCR locking properties and therefore gets aware
of unlocked event nodes with the active flag set to true. If an application node finds such
a node, it locks it, updates the <em>event:application</em> information and processes
it accordingly. In this case the event gets the additional property <em>org/apache/sling/job/retry</em>.
</p>

<p>Each application is periodically removing old jobs from the repository (using the
scheduler).</p>



<h3><a name="ApacheSlingEventingandJobHandling-DistributionofJobs"></a>Distribution
of Jobs</h3>

<p>A job event is an event like any other. Therefore it is up to the client generating
the event to decide if the event should be distributed. If the event is distributed, it will
be distributed with a set <em>event.application</em> on the remote nodes. If the
job event handler receives a job with the <em>event.application</em> property
set, it will not try to write it into the repository. It will just broadcast this event asynchronously
as a ~FYI event.</p>

<p>If a job event is created simultanously on all application nodes, the event will
not be distributed. The application node that actually has the lock on the stored job in the
repository will clear the <em>event.application</em> when sending the event locally.
All other application nodes will use the <em>event.application</em> stored in
the repository when broadcasting the event locally.</p>

<h2><a name="ApacheSlingEventingandJobHandling-UsagePatterns"></a>Usage
Patterns</h2>

<p>Based on some usage patterns, we discuss the functionality of the eventing mechanism.</p>

<h3><a name="ApacheSlingEventingandJobHandling-SendingUserGeneratedEvents"></a>Sending
User Generated Events</h3>

<p>If a user action results in an event, the event is only created on one single node
in the cluster. The event object is generated and delivered to the OSGi event admin. If the
<em>event.distribute</em> is not explicitly set, the event is only distributed
localled.</p>

<p>If the <em>event.distribute</em> is the, the cluster event handler will
write the event into the repository. All nodes in the cluster observe the repository area
where all events are stored. If a new event is written into that area, each application node
will get notified. It will create the event based on the information in the repository, clear
the <em>event.distribute</em> and publish the event.</p>

<p>The flow can be described as follows:</p>
<ol>
	<li>Client code generates event using OSGi API, if the <em>event.distribute</em>
should be set, it is using the ~EventUtil.</li>
	<li>Client code sends the event to the (local) event admin.</li>
	<li>Event admin delivers the event locally.</li>
	<li>Clustering event handler receives the event if <em>event.distribute</em>
is present
	<ol>
		<li>Event handler adds <em>event.application</em> and writes the event
to the repository</li>
		<li>Remote repository observers get notified through JCR observation about the new
event. They distribute the event locally with the <em>event.application</em> (from
the node where the event occured first) and cleared <em>event.distribute</em>.</li>
	</ol>
	</li>
</ol>


<h3><a name="ApacheSlingEventingandJobHandling-ProcessingJCREvents"></a>Processing
JCR Events</h3>

<p>JCR events are environment generated events and therefore are sent by the repository
to each node in the cluster. In general, it is advisable to not built the application on the
low level repository events but to use application events. Therefore the observer of the JCR
event should create an OSGi event based on the changes in the repository. A decision has to
be made if the event should be a job or a plain event.</p>

<p>The flow can be described as follows:</p>
<ol>
	<li>Client registers for JCR observation</li>
	<li>JCR notifies the client for changes</li>
	<li>Client generates OSGi event based on the JCR events (the <em>event.distribute</em>
will not be set), it decides if it sends this event as a job.</li>
	<li>Client code sends the event to the (local) event admin</li>
	<li>Event admin publishes the event locally</li>
	<li>The distribution event handler does not set see the event as the <em>event.distribute</em>
is not set.</li>
	<li>The job event handler gets the event if it has the job topic
	<ol>
		<li>The job event handler adds the <em>event.application</em> property
and tries to write the job to the repository
		<ol>
			<li>If no job with the topic and <em>id</em> property is in the repository,
the event will be written and locked.</li>
			<li>If an event with the topic and <em>id</em> property is in the repository
then:
			<ol>
				<li>If the <em>event.application</em> equals the current application
node, the event is set to active (<em>event:active</em>) in the repository again
and locked</li>
				<li>If the <em>event.application</em> does not equal the current application
node, the event is not distributed locally.</li>
			</ol>
			</li>
			<li>If the job could be locked in the repository, the job event handler delivers
the job locally and synchronously and it unlocks the job and sets <em>event:active</em>
to false afterwards.</li>
		</ol>
		</li>
	</ol>
	</li>
</ol>


<h3><a name="ApacheSlingEventingandJobHandling-SendingScheduledEvents"></a>Sending
Scheduled Events</h3>

<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>

<p>In most use cases a scheduler will send job events to ensure that exactly one application
node is processing the event.</p>

<h3><a name="ApacheSlingEventingandJobHandling-ReceivingOSGiEvents"></a>Receiving
OSGi Events</h3>

<p>If you want to receive OSGi events, you can just follow the specification: receive
it via a custom event handler which is registered on bundle start - a filter can be specified
as a configuration property of the handler. </p>

<p>As we follow the principle of distributing each event to every registered handler,
the handler has to decide if it will process the event. In order to avoid multiple processing
of this event in a clustered environment, the event handler should check the <em>event.application</em>
property. If it is not set, it's a local event and the handler should process the event. If
the <em>event.application</em> is set, it's a remote event and the handler should
not process the event. This is a general rule of thumb - however, it's up to the handler to
make its decision either on <em>event.application</em> or any other information.</p>

<p>It is advisable to perform the local event check even in a non clustered environment
as it makes the migration to a cluster later on much easier and there is nearly no performance
overhead caused by the check.</p>

<p>The ~EventUtil class provides an utility method <em>isLocalEvent(Event)</em>
which checks the existance of the <em>event.application</em> property and returns
<em>true</em> if it is absend.</p>

<p><a name="ApacheSlingEventingandJobHandling-distributed"></a></p>
<h2><a name="ApacheSlingEventingandJobHandling-DistributedEvents"></a>Distributed
Events</h2>

<p>In addition to the job handling, the Sling Event support adds handling for distributed
events. A distributed event is an OSGi event which is sent across JVM boundaries to a different
VM. A potential use case is to broadcast information in a clustered environment.</p>

<h3><a name="ApacheSlingEventingandJobHandling-SourcesofEvents"></a>Sources
of Events</h3>

<p>When it comes to application based on Sling, there is a variety of sources from which
OSGi events can be send:</p>
<ul>
	<li>JCR observation events</li>
	<li>Application generated events</li>
	<li>Events from messaging systems (~JMS)</li>
	<li>"External events"</li>
</ul>


<p>The events can eiter be generated inside a current user context, e.g. when the user
performs an action through the UI, or they can be out of a user context, e.g. for schedulded
events. This leads to different weights of events.</p>

<h3><a name="ApacheSlingEventingandJobHandling-WeightsofEvents"></a>Weights
of Events</h3>

<p>We can distinguish two different weights of events, depending how they are distributed
in a clustered environment:</p>

<ul>
	<li>User generated events - these events are generated directly by some user action
and are therefore started on one single node.</li>
	<li>Environment generated events (JCR events, scheduler events etc.) - these events
are generated "simultanously" on all nodes.</li>
</ul>


<p>External events, like incoming JMS events etc. might fall either into the first or
the second category. The receiver of such events must have the knowledge about the weight
of the event.</p>

<h3><a name="ApacheSlingEventingandJobHandling-BasicPrinciples"></a>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, however the sender must explicitly declare
an event to be distributed. There are exceptions to "distributing everything to everywhere"
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>The event mechanism is an <b>event</b> mechanism which should not be
confused with a <b>messaging</b> mechanism. Events are received by the event mechanism
and distributed to registered listeners. Concepts like durable listeners, guarantee of processing
etc. are not part of the event mechanism itself. However, there is additional support for
such things, like job handling.</p>

<p>The application should try to use application events instead of low level JCR events
whereever possible. Therefore a bridging between JCR events and the event mechanism is required.
However, a general "automatic" mapping will not be provided. It is up to the application to
develop such a mapping on a per use case base. There might be some support to make the mapping
easier.</p>

<p>The event handling should be made as transparent to the developer as possible. Therefore
the additional code for a developer to make the eventing working in a clustered environment
etc. should be kept to a minimum (which will hopefully reduce possible user errors).</p>

<h3><a name="ApacheSlingEventingandJobHandling-DistributedEvents"></a>Distributed
Events</h3>

<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 <b>never</b>
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><a name="ApacheSlingEventingandJobHandling-EventDistributionAcrossApplicationNodes%28Cluster%29"></a>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, the JCR repository is used for distribution.
The distributing event handler writes the events into the repository, the distributing event
handlers on other application nodes get notified through observation and then distribute the
read events locally.</p>

<p>As mentioned above, the client sending an event has to mark an event to be distributed
in a cluster by setting the <em>event.distribute</em> in the event properties
(through <em>EventUtil</em>). This distribution mechanism has the advantage that
the application nodes do not need to know each other and the distribution mechanism is independent
from the used event admin implementation.</p>

<h3><a name="ApacheSlingEventingandJobHandling-StoringEventsintheRepository"></a>Storing
Events in the Repository</h3>

<p>Distributable events are stored in the repository, the repository will have a specific
area (path) where all events are stored. </p>

<p>Each event is stored as a separate node with the following properties:</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <b>Property Name</b>     </td>
<td class='confluenceTd'> <b>Description</b> </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:topic</em>       </td>
<td class='confluenceTd'> The topic of the event </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:application</em> </td>
<td class='confluenceTd'> The identifier of the application node where the event was
created </td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:created</em>     </td>
<td class='confluenceTd'> The date and time when the event has been created (stored
in the repository)</td>
</tr>
<tr>
<td class='confluenceTd'> <em>event:properties</em>  </td>
<td class='confluenceTd'> Serialized properties (except the <em>event.distribute</em>,
but including the <em>event.application</em>) </td>
</tr>
</tbody></table>
</div>


<p>Each application is periodically removing old events from the repository (using the
scheduler).</p>


<p><a name="ApacheSlingEventingandJobHandling-timed"></a></p>
<h3><a name="ApacheSlingEventingandJobHandling-SendingScheduledEvents"></a>Sending
Scheduled Events</h3>

<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>

<p>In most use cases a scheduler will send job events to ensure that exactly one application
node is processing the event.</p>

<h3><a name="ApacheSlingEventingandJobHandling-ReceivingOSGiEvents"></a>Receiving
OSGi Events</h3>

<p>If you want to receive OSGi events, you can just follow the specification: receive
it via a custom event handler which is registered on bundle start - a filter can be specified
as a configuration property of the handler. </p>

<p>As we follow the principle of distributing each event to every registered handler,
the handler has to decide if it will process the event. In order to avoid multiple processing
of this event in a clustered environment, the event handler should check the <em>event.application</em>
property. If it is not set, it's a local event and the handler should process the event. If
the <em>event.application</em> is set, it's a remote event and the handler should
not process the event. This is a general rule of thumb - however, it's up to the handler to
make its decision either on <em>event.application</em> or any other information.</p>

<p>It is advisable to perform the local event check even in a non clustered environment
as it makes the migration to a cluster later on much easier and there is nearly no performance
overhead caused by the check.</p>

<p>The ~EventUtil class provides an utility method <em>isLocalEvent(Event)</em>
which checks the existance of the <em>event.application</em> property and returns
<em>true</em> if it is absend.</p>

<h2><a name="ApacheSlingEventingandJobHandling-Scheduler"></a>Scheduler</h2>

<p>Each Sling based application will contain a scheduler service (which is based on
the Quartz open source project).</p>

<h2><a name="ApacheSlingEventingandJobHandling-UseCases"></a>Use Cases</h2>

<h3><a name="ApacheSlingEventingandJobHandling-PostProcessing%28BusinessProcesses%29"></a>Post
Processing (Business Processes)</h3>

<p>A typical example for post processing (or running a business process) is sending
an email or creating thumbnails and extracting meta data from the content (like we do in DAM),
which we will discuss here.</p>

<p>An appropriate JCR observer will be registered. This observer detects when new content
is put into the repository or when content is changed. In these cases it creates appropriate
<em>CONTENT_ADDED</em>, <em>CONTENT_UPDATED</em> OSGi events from
the JCR events. In order to ensure that these actions get processed accordingly, the event
is send as a job (with the special job topic, the <em>topic</em> and <em>id</em>
property).</p>

<p>The event admin now delivers these jobs to the registered handlers. The job event
handler gets notified and (simplified version) sends the contained event synchronously. One
of the handlers for these events is the post processing service in DAM. The job mechanism
ensures that exactly one application node is post processing and that the process has to be
finished even if the application node dies during execution.</p>

<h2><a name="ApacheSlingEventingandJobHandling-Scheduling"></a>Scheduling</h2>

<p>The scheduler is a service which uses the open source Quartz library. The scheduler
has methods to start jobs periodically or with a cron definition. In addition, a service either
implementing <em>java.lang.Runnable</em> or <em>org.quartz.job</em>
is started through the whiteboard pattern <b>if</b> it either contains a configuration
property <em>scheduler.expression</em> or <em>scheduler.period</em>.
The job is started with the ~PID of the service - if the service has no PID, the configuration
property <em>scheduler.name</em> must be set.</p>
    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/Apache+Sling+Eventing+and+Job+Handling">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=24183351&revisedVersion=12&originalVersion=11">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/Apache+Sling+Eventing+and+Job+Handling?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message