Author: buildbot
Date: Wed May 22 12:26:43 2013
New Revision: 862737
Log:
Staging update by buildbot for sling
Modified:
websites/staging/sling/trunk/content/ (props changed)
websites/staging/sling/trunk/content/documentation/bundles/discovery-api-and-impl.html
Propchange: websites/staging/sling/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed May 22 12:26:43 2013
@@ -1 +1 @@
-1485168
+1485185
Modified:
websites/staging/sling/trunk/content/documentation/bundles/discovery-api-and-impl.html
==============================================================================
---
websites/staging/sling/trunk/content/documentation/bundles/discovery-api-and-impl.html
(original)
+++
websites/staging/sling/trunk/content/documentation/bundles/discovery-api-and-impl.html
Wed May 22 12:26:43 2013
@@ -18,7 +18,7 @@
limitations under the License.
-->
<head>
- <title>Apache Sling - Discovery API and its Implementations</title>
+ <title>Apache Sling - Discovery API and its implementations</title>
<link rel="icon" href="/res/favicon.ico">
<link rel="stylesheet" href="/res/site.css" type="text/css" media="all">
<link rel="stylesheet" href="/res/codehilite.css" type="text/css"
media="all">
@@ -85,10 +85,10 @@
- <h1>Discovery API and its Implementations</h1>
- <p>In many situations a particular Sling-based deployment consists of
more than one Sling-instances:
-typically a number of instances would form a <code>cluster</code> that share a
common repository -
-in other situations, or additionally, instances might be loosely-coupled, each
with their own repository.</p>
+ <h1>Discovery API and its implementations</h1>
+ <p>In many situations a particular Sling-based deployment consists of
several Sling instances:
+typically a number of instances would form a <code>cluster</code> that share a
common content repository -
+in other situations, or additionally, instances might be loosely coupled, each
with their own repository.</p>
<p>The <code>discovery-api</code> bundle introduces an abstraction for such
scenarios called <code>topology</code>. It provides
access to the current topology, allows to be informed of any changes in the
topology (such as joining or leaving
instances) and contains a simple property exchange mechanism, e.g. to allow
building communication services on top of it.</p>
@@ -98,7 +98,7 @@ instances) and contains a simple propert
<li><a href="#cluster-leader-and-instance-ordering">Cluster Leader and
Instance Ordering</a></li>
<li><a href="#topology-changes">Topology Changes</a></li>
<li><a href="#properties">Properties</a></li>
-<li><a href="#deployment-configuration">Deployment, Configuration</a></li>
+<li><a href="#deployment-and-configuration">Deployment and
configuration</a></li>
<li><a
href="#discoveryimpl-resource-based-ootb-implementation">discovery.impl:
Resource-based, OOTB Implementation</a><ul>
<li><a href="#location-in-repository">Location in Repository</a></li>
<li><a href="#connectors">Connectors</a></li>
@@ -109,9 +109,9 @@ instances) and contains a simple propert
</ul>
</div>
<h2 id="topology">Topology</h2>
-<p>The topology - or more precisely the <code>TopologyView</code> - represents
a snapshot (<code>view</code>) of a number of loosely-coupled Sling instances
(<code>InstanceDescription</code>)
+<p>The topology - or more precisely the <code>TopologyView</code> - represents
a snapshot (<code>view</code>) of a number of loosely coupled Sling instances
(<code>InstanceDescription</code>)
and clusters (<code>ClusterView</code>) of a particular deployment. A cluster
can consist of one or more instances. Each instance
-is always automatically part to a cluster (even if the cluster only consists
of one instance).
+is always part of a cluster (even if the cluster consists of only one
instance).
Each instance and cluster has an identifier.
Other than this cluster-instance relation there is no further
assumption made on the structure of a topology. Therefore if the actual
structure is of a different shape (such as a tree)
@@ -126,15 +126,16 @@ deal with work that must be guaranteed t
at the end of the list and retains its order in the list as long as it doesn't
leave the cluster. This can be used
to distribute "singleton" work amongst the cluster to more than just the
leader. </p>
<h2 id="topology-changes">Topology Changes</h2>
-<p>The <code>DiscoveryService</code> provides access to the currently valid
<code>TopologyView</code>. Additionally applications can
+<p>The <code>DiscoveryService</code> provides access to the currently valid
<code>TopologyView</code>. Additionally, applications can
register a <code>TopologyEventListener</code> and thus be informed about any
changes in the topology. Whenever the discovery
-service detects that an instance is no longer reponding or has newly joined,
or a new leader has been elected,
+service detects that an instance is no longer responding or has newly joined,
or a new leader has been elected,
it sends a <code>TOPOLOGY_CHANGING</code> event, starts
-settling the change within the topology (ie making sure everybody else in the
topology agrees on the change) and finally
-sends a <code>TOPOLOGY_CHANGED</code> event with the new topology.
-Additionally, when "only" properties have changed, a
<code>PROPERTIES_CHANGED</code> event is sent.</p>
+settling the change within the topology (i.e. making sure everybody else in
the topology agrees with the change) and finally
+sends a <code>TOPOLOGY_CHANGED</code> event with the new topology.</p>
+<p>Additionally, when "only" properties have changed, a
<code>PROPERTIES_CHANGED</code> event is sent.</p>
<p>Note that the detection of topology (or properties) changes will incur a
delay which is implementation dependent.</p>
-<p>The following is an example of a listener - note that the binding is done
automatically by OSGi:</p>
+<p>The following is an example of a listener. Note that the binding is done
automatically by OSGi, as soon as a
+<code>TopologyEventListener</code> is registered.</p>
<div class="codehilite"><pre><span class="nb">import</span> <span
class="n">org</span><span class="o">.</span><span class="n">apache</span><span
class="o">.</span><span class="n">felix</span><span class="o">.</span><span
class="n">scr</span><span class="o">.</span><span
class="n">annotations</span><span class="o">.</span><span
class="n">Component</span><span class="p">;</span>
<span class="nb">import</span> <span class="n">org</span><span
class="o">.</span><span class="n">apache</span><span class="o">.</span><span
class="n">felix</span><span class="o">.</span><span class="n">scr</span><span
class="o">.</span><span class="n">annotations</span><span
class="o">.</span><span class="n">Service</span><span class="p">;</span>
<span class="nb">import</span> <span class="n">org</span><span
class="o">.</span><span class="n">apache</span><span class="o">.</span><span
class="n">sling</span><span class="o">.</span><span
class="n">discovery</span><span class="o">.</span><span
class="n">TopologyEvent</span><span class="p">;</span>
@@ -154,13 +155,13 @@ Additionally, when "only" properties hav
<h2 id="properties">Properties</h2>
<p>The discovery API not only lists all clusters and instances that are part
of a topology but also provides a simple
-mechanism for announcing properties of each instance to the topology. This can
be achieved via the <code>PropertyProvider</code>.
-Typical use cases for this are announcements of endpoint-URLs or ports such
that applications can communicate to other
+mechanism for announcing properties of each instance to the topology, via the
<code>PropertyProvider</code> service interface.</p>
+<p>Typical use cases for this are announcements of endpoint URLs or ports such
that applications can communicate to other
instances in the topology.</p>
-<p>Note that the properties mechanism is by no means to be used as a messaging
tool: both from an API point of view and
-the implementation of it are not optimized for frequent changes and its use
for messaging is discouraged. Instead
-it should be used to announce configuration information for accessing proper
messaging services.</p>
-<p>The following is an example of a PropertyProvider, providing
<code>sample.value1</code> and <code>sample.value2</code> properties:</p>
+<p>Note that the properties mechanism is not meant be used as a messaging
tool: both from an API point of view and
+the implementation of it are not optimized for frequent changes and its use
for messaging is discouraged. It is only
+meant to be used to announce configuration information for accessing proper
messaging services.</p>
+<p>The following is an example of a <code>PropertyProvider</code> that
provides <code>sample.value1</code> and <code>sample.value2</code>
properties:</p>
<div class="codehilite"><pre><span class="nb">import</span> <span
class="n">org</span><span class="o">.</span><span class="n">apache</span><span
class="o">.</span><span class="n">felix</span><span class="o">.</span><span
class="n">scr</span><span class="o">.</span><span
class="n">annotations</span><span class="o">.</span><span
class="n">Component</span><span class="p">;</span>
<span class="nb">import</span> <span class="n">org</span><span
class="o">.</span><span class="n">apache</span><span class="o">.</span><span
class="n">felix</span><span class="o">.</span><span class="n">scr</span><span
class="o">.</span><span class="n">annotations</span><span
class="o">.</span><span class="n">Service</span><span class="p">;</span>
<span class="nb">import</span> <span class="n">org</span><span
class="o">.</span><span class="n">apache</span><span class="o">.</span><span
class="n">sling</span><span class="o">.</span><span
class="n">discovery</span><span class="o">.</span><span
class="n">PropertyProvider</span><span class="p">;</span>
@@ -183,12 +184,12 @@ it should be used to announce configurat
</pre></div>
-<h2 id="deployment-configuration">Deployment, Configuration</h2>
+<h2 id="deployment-and-configuration">Deployment and configuration</h2>
<p>The discovery API makes no assumptions as to how the instances and clusters
discovery each other. This is entirely
-up to the implementations. Some might choose to automatic discovery within a
local LAN using IP multicast, some
-might choose to explicit configuration with a central service etc.</p>
+up to the implementations. Some might choose automatic discovery within a LAN
using IP multicast, others
+might choose explicit configuration via a central service etc.</p>
<h2 id="discoveryimpl-resource-based-ootb-implementation">discovery.impl:
Resource-based, OOTB Implementation</h2>
-<p>The <code>discovery.impl</code> is a resource-based, out of the box
implementation using standard Sling. The discovery within
+<p>The <code>discovery.impl</code> bundle is a resource-based, out of the box
implementation using standard Sling. The discovery within
a cluster is done by writing heartbeat information into the (common)
repository. The establishment of a clusterview
is done by analyzing these heartbeats, initiating a voting within the cluster
(such that each instance can agree
that it sees the same number of instances) and by concluding the voting by
promoting it as the new "established" view.</p>
@@ -199,13 +200,12 @@ that it sees the same number of instance
<h3 id="connectors">Connectors</h3>
-<p>The announcement "cross-cluster" is done via HTTP(s) heartbeats between
(arbitrary) cluster instances. These HTTP-heartbeats
-(internally termed <code>connectors</code>) must be configured <a
href="http://localhost:4502/system/console/configMgr/org.apache.sling.discovery.impl.Config";>here</a>.</p>
+<p>The "cross-cluster" announcement is done via HTTP(s) heartbeats between
(arbitrary) cluster instances. These HTTP heartbeats
+(internally termed <code>connectors</code>) are configured at <a
href="http://localhost:8888/system/console/configMgr/org.apache.sling.discovery.impl.Config";>/system/console/configMgr/org.apache.sling.discovery.impl.Config</a>.</p>
<h3 id="webconsole">WebConsole</h3>
-<p>There is a Felix-based WebConsole that provides a (read-only) overview of
the topology.
-It can be found here: <a
href="http://localhost:4502/system/console/topology";>http://localhost:4502/system/console/topology</a>.</p>
+<p>A Felix WebConsole plugin at <a
href="http://localhost:8888/system/console/topology";>/system/console/topology</a>
provides a (read-only) overview of the topology.</p>
<h3 id="configuration">Configuration</h3>
-<p>The following properties can be configured (<a
href="http://localhost:4502/system/console/configMgr/org.apache.sling.discovery.impl.Config";>here</a>):</p>
+<p>The following properties can be configured (at <a
href="http://localhost:8888/system/console/configMgr/org.apache.sling.discovery.impl.Config";>/system/console/configMgr/org.apache.sling.discovery.impl.Config</a>):</p>
<ul>
<li>
<p>heartbeatInterval: the time in seconds between two heartbeats (both
cluster-internal and for HTTP-connectors). Default
@@ -237,7 +237,7 @@ It can be found here: <a href="http://lo
</li>
</ul>
<div class="timestamp" style="margin-top: 30px; font-size: 80%;
text-align: right;">
- Rev. 1485168 by stefanegli on Wed, 22 May 2013 11:59:19 +0000
+ Rev. 1485185 by bdelacretaz on Wed, 22 May 2013 12:26:37 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache
Sling project
