anchor.diff:  The _nifi.properties_ file in the _conf_ directory is the main configuration file for controlling how NiFi runs. This section provides an overview of the properties in this file and includes some notes on how to configure it in a way that will make upgrading easier. *After making changes to this file, restart NiFi in order
   for the changes to take effect.*
   
  -NOTE: The contents of this file are relatively stable but do change from time to time. It is always a good idea to 
  +NOTE: The contents of this file are relatively stable but do change from time to time. It is always a good idea to
   review this file when upgrading and pay attention for any changes. Consider configuring items
  -below marked with an asterisk (*) in such a way that upgrading will be easier. For details, see a full discussion on upgrading 
  -at the end of this section. Note that values for periods of time and data sizes must include the unit of measure, 
  +below marked with an asterisk (*) in such a way that upgrading will be easier. For details, see a full discussion on upgrading
  +at the end of this section. Note that values for periods of time and data sizes must include the unit of measure,
   for example "10 sec" or "10 MB", not simply "10".
   
   *Core Properties* +
  
positive.code: 
  *Nodes*: Each cluster is made up of the NCM and one or more nodes. The nodes do the actual data processing. (The NCM does not process any data; all data runs through the nodes.)  While nodes are connected to a cluster, the DFM may not access the User Interface for any of the individual nodes. The User Interface of a node may only be accessed if the node is manually removed from the cluster.
  
  *Primary Node*: Every cluster has one Primary Node. On this node, it is possible to run "Isolated Processors" (see below). By default, the NCM will elect the first node that connects to the cluster as the Primary Node; however, the DFM may select a new node as the Primary Node in the Cluster Management page of the User Interface if desired. If the cluster restarts, the NCM will "remember" which node was the Primary Node and wait for that node to re-connect before allowing the DFM to make any changes to the dataflow. The ADMIN may adjust how long the NCM waits for the Primary Node to reconnect by adjusting the property _nifi.cluster.manager.safemode.duration_ in the _nifi.properties_ file, which is discussed in the <<system_properties>> section of this document. 
  
  *Isolated Processors*: In a NiFi cluster, the same dataflow runs on all the nodes. As a result, every component in the flow runs on every node. However, there may be cases when the DFM would not want every processor to run on every node. The most common case is when using a processor that communicates with an external service using a protocol that does not scale well. For example, the GetSFTP processor pulls from a remote directory, and if the GetSFTP on every node in the cluster tries simultaneously to pull from the same remote directory, there could be race conditions. Therefore, the DFM could configure the GetSFTP on the Primary Node to run in isolation, meaning that it only runs on that node. It could pull in data and -with the proper dataflow configuration- load-balance it across the rest of the nodes in the cluster. Note that while this feature exists, it is also very common to simply use a standalone NiFi instance to pull data and feed it to the cluster. It just depends on the resources available and how the Administrator decides to configure the cluster.
  
  *Heartbeats*: The nodes communicate their health and status to the NCM via "heartbeats", which let the NCM know they are still connected to the cluster and working properly. By default, the nodes emit heartbeats to the NCM every 5 seconds, and if the NCM does not receive a heartbeat from a node within 45 seconds, it disconnects the node due to "lack of heartbeat". (The 5-second and 45-second settings are configurable in the _nifi.properties_ file. See the <<system_properties>> section of this document for more information.) The reason that the NCM disconnects the node is because the NCM needs to ensure that every node in the cluster is in sync, and if a node is not heard from regularly, the NCM cannot be sure it is still in sync with the rest of the cluster. If, after 45 seconds, the node does send a new heartbeat, the NCM will automatically reconnect the node to the cluster. Both the disconnection due to lack of heartbeat and the reconnection once a heartbeat is received are reported to the DFM in the NCM's User Interface. 
  
  *Communication within the Cluster* +
  
  
negative.code:         <id>some-identifier</id>
          <!-- The fully-qualified class name of the Notification Service. -->
          <class>org.apache.nifi.bootstrap.notification.email.EmailNotificationService</class>
  
          <!-- Any number of properties can be set using this syntax.
               The properties available depend on the Notification Service. -->
          <property name="Property Name 1">Property Value</property>
          <property name="Another Property Name">Property Value 2</property>
  