<html>
<head>
    <base href="https://wiki.asterisk.org/wiki">
            <link rel="stylesheet" href="/wiki/s/2042/1/7/_/styles/combined.css?spaceKey=TOP&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://wiki.asterisk.org/wiki/display/TOP/Replication+of+Configuration+Changes">Replication of Configuration Changes</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</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" >After each of the initialization sequence vignettes have completed, Figure 1 shows the Component&#39;s Configurator accessing the ConfigurationService interface from the ServiceLocator. Since the StateReplicator registered the Topic as the ConfigurationService, the configuration data is pushed to all of the components in the replica group, transparently to the Configurator.  <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">While it isn&#39;t shown on the diagram, the StateReplicator can add its own listener to the topic, which it would use to maintain a cache of the current configuration state. This cache would be pushed to each component&#39;s ConfigurationService interface as part of the registration process in the StateReplicator, before it is subscribed to the topic. This will allow late-joining components to be placed into the same configuration as those that were initialized prior to any Configurator operation.  <br> <br></td></tr>
            <tr><td class="diff-unchanged" >| !ConfigReplication.png|border=1! | <br>| {center}{*}Figure 1. Configuration Replication{*}{center} | <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h3><a name="ReplicationofConfigurationChanges-Overview"></a>Overview</h3>
<p><a href="/wiki/display/TOP/Distributed+State+Replication" title="Distributed State Replication">State Replication</a> and <a href="/wiki/display/TOP/Configuration+Pattern" title="Configuration Pattern">Configuration</a> are described on other pages in this section. This pages describes how configuration is pushed to all components in a replica group (i.e. the active component, and it's related standby component.) </p>

<h3><a name="ReplicationofConfigurationChanges-Description"></a>Description</h3>

<p>As seen in Figure 1 below, the State Replicator will create an IceStorm topic during initialization to enable forwarding ConfigurationService operations to all components within a replica group. It registers a proxy to the topic with the ServiceLocator using the same parameters that the component would have used to register it's ConfigurationService interface if it had been brought up outside of a replica group. </p>

<p>When an Asterisk SCF is brought up as part of a replica group, it will register its ConfigurationService interface with its StateReplicator rather than directly with the ServiceLocator during initialization. The StateReplicator will subscribe the proxy to the Topic created during initialization. </p>

<p>After each of the initialization sequence vignettes have completed, Figure 1 shows the Component's Configurator accessing the ConfigurationService interface from the ServiceLocator. Since the StateReplicator registered the Topic as the ConfigurationService, the configuration data is pushed to all of the components in the replica group, transparently to the Configurator. </p>

<p>While it isn't shown on the diagram, the StateReplicator can add its own listener to the topic, which it would use to maintain a cache of the current configuration state. This cache would be pushed to each component's ConfigurationService interface as part of the registration process in the StateReplicator, before it is subscribed to the topic. This will allow late-joining components to be placed into the same configuration as those that were initialized prior to any Configurator operation. </p>

<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'> <span class="image-wrap" style=""><img src="/wiki/download/attachments/13076604/ConfigReplication.png?version=1&amp;modificationDate=1305241339559" style="border: 1px solid black" /></span> </td>
</tr>
<tr>
<td class='confluenceTd'> <div class="" align="center"><b>Figure 1. Configuration Replication</b></div>
 </td>
</tr>
</tbody></table>
</div>


    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://wiki.asterisk.org/wiki/display/TOP/Replication+of+Configuration+Changes">View Online</a>
        |
        <a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=13076604&revisedVersion=3&originalVersion=2">View Changes</a>
                |
        <a href="https://wiki.asterisk.org/wiki/display/TOP/Replication+of+Configuration+Changes?showComments=true&amp;showCommentArea=true#addcomment">Add Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>