Author: buildbot
Date: Thu Apr 9 12:37:52 2015
New Revision: 946886
Log:
Staging update by buildbot for slider
Modified:
websites/staging/slider/trunk/content/ (props changed)
websites/staging/slider/trunk/content/design/rolehistory.html
Propchange: websites/staging/slider/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Apr 9 12:37:52 2015
@@ -1 +1 @@
-1670184
+1672317
Modified: websites/staging/slider/trunk/content/design/rolehistory.html
==============================================================================
--- websites/staging/slider/trunk/content/design/rolehistory.html (original)
+++ websites/staging/slider/trunk/content/design/rolehistory.html Thu Apr 9
12:37:52 2015
@@ -195,6 +195,30 @@ that have reached their escalation timeo
request. YARN may still allocate relaxed instances on such nodes. That is:
there is no explicit
blacklisting, merely deliberate exclusion of unreliable nodes from explicitly
placed requests.</li>
</ol>
+<p>Role History Reloading Enhancements</p>
+<p>How persisted role history has also been improved
[SLIDER-600]((https://issues.apache.org/jira/browse/SLIDER-600)</p>
+<ol>
+<li>Reloading of persistent history has been made resilient to changes in the
number of roles.</li>
+<li>If there are more roles in the history than the current set, the surplus
entries
+are discarded.</li>
+<li>If there are fewer, then the smaller set of roles are loaded</li>
+<li>The mapping of role name to role ID is persisted.</li>
+<li>There are tests to verify that the original role histories (those without
maps) are reloaded.</li>
+</ol>
+<p>There are no checks that the mapping of name to ID has not changed; the
current model
+is "don't do that". If it is done while an application instance is stopped,
the rebuilt
+placement may hurt performance of those roles which require an absolute
location.
+If it is done during AM restart, the AM will be unable to reliably rebuild its
+state model. SLIDER-849 proposes future handling of these situations. By
saving the current
+rolename to ID mappings, the placement history will be ready for such a
feature when it
+is implemented.</p>
+<p>The enhanced role history format is backwards compatible; there are tests
to verify that.
+However Slider 0.70 and earlier cannot process the 0.80 version entries. If
there are problems
+reloading entries there are two tactics</p>
+<ol>
+<li>Delete the JSON files</li>
+<li>Edit the most recent JSON file and delete any entry with the type
<code>RoleHistoryMapping</code>.</li>
+</ol>
<h4 id="placement-policies">Placement policies</h4>
<p><code>strict</code> placement</p>
<p>Again, "strict placement" has a different policy: once a component has been
deployed on a node,
