DOC-383 Removed two sections from Notify Container topic

PeninaR · PeninaR · commit 1f494affca9c · 2018-07-01T11:44:07.000+03:00
Primary/Backup section, Triggering notification on backup instances section
diff --git a/site/content/xap/12.0/dev-java/notify-container.markdown b/site/content/xap/12.0/dev-java/notify-container.markdown
@@ -151,19 +151,6 @@ To avoid this behavior, the notify listener implementation should have [batching
 If the listener performs a large number of space operations, a [polling container](./polling-container.html#notify-verses-polling-container) should be considered as this is a more controlled event handler.
 
 
-
-# Primary/Backup
-
-By default, the notify event container registers for notifications only when the relevant space it is working against is in primary mode. When the space is in backup mode, no registration occurs. If the space moves from backup mode to primary mode, the container registers for notifications, and if it moved to backup mode, the registrations are canceled.
-
- 
-This mostly applies when working with an embedded space directly with a cluster member. When working with a clustered space (performing operations against the whole cluster), the mode of the space is always primary.
- 
-
-{{% note "NOTIFY_LEASE_EXPIRATION"%}}
-Notifications for expired objects (NOTIFY_LEASE_EXPIRATION type) are sent both from the primary and the backup space. To avoid this, you should set the Notify Container `replicateNotifyTemplate` to `false` and run the notify container collocated with the space. This will start the Notify Container only with the primary and will avoid duplicated notifications.
-{{%/note%}}
-
 # Template Definition
 
 When performing receive operations, a template is defined, creating a virtualized subset of data in the space, matching it. XAP supports templates based on the actual domain model (with `null` values denoting wildcards), which are shown in the examples. XAP allows the use of [SQLQuery](./query-sql.html) in order to query the space, which can be easily used with the event container as the template. Here is an example of how it can be defined:
@@ -978,25 +965,6 @@ When a network failure occurs and the space can't communicate with the client, t
 {{% include "/COM/notify-recovery.markdown" %}}
 
 
-# Triggering Notifications on Backup Instances
-
-By default notifications are replicated to backup instances but are not triggered. To enable notifications triggered also on backup instances the `cluster-config.groups.group.repl-policy.trigger-notify-templates` should be enabled. See below:
-
-
-```xml
-<os-core:space id="space" url="/./space" >	
-	<os-core:properties>
-		<props>
-			<prop key="cluster-config.groups.group.repl-policy.trigger-notify-templates">true</prop>
-		</props>
-	</os-core:properties>
-</os-core:space>
-```
-
-{{% note %}}
-When this option is enabled - When running collocated notify container the listener implementation should not access its collocated instance as this is blocked with backup instances.  
-{{%/note%}}
-
 # Durable Notifications
 
 Due-to the asynchronous nature of notification delivery, when a primary space fails right after replicating an operation to the backup space and before sending the notification to the registered client, the backup space might not be able to send the missing notifications, since it is in the process of moving to active mode.
diff --git a/site/content/xap/12.1/dev-java/notify-container.markdown b/site/content/xap/12.1/dev-java/notify-container.markdown
@@ -151,19 +151,6 @@ To avoid this behavior, the notify listener implementation should have [batching
 If the listener performs a large number of space operations, a [polling container](./polling-container.html#notify-verses-polling-container) should be considered as this is a more controlled event handler.
 
 
-
-# Primary/Backup
-
-By default, the notify event container registers for notifications only when the relevant space it is working against is in primary mode. When the space is in backup mode, no registration occurs. If the space moves from backup mode to primary mode, the container registers for notifications, and if it moved to backup mode, the registrations are canceled.
-
- 
-This mostly applies when working with an embedded space directly with a cluster member. When working with a clustered space (performing operations against the whole cluster), the mode of the space is always primary.
- 
-
-{{% note "NOTIFY_LEASE_EXPIRATION"%}}
-Notifications for expired objects (NOTIFY_LEASE_EXPIRATION type) are sent both from the primary and the backup space. To avoid this, you should set the Notify Container `replicateNotifyTemplate` to `false` and run the notify container collocated with the space. This will start the Notify Container only with the primary and will avoid duplicated notifications.
-{{%/note%}}
-
 # Template Definition
 
 When performing receive operations, a template is defined, creating a virtualized subset of data in the space, matching it. XAP supports templates based on the actual domain model (with `null` values denoting wildcards), which are shown in the examples. XAP allows the use of [SQLQuery](./query-sql.html) in order to query the space, which can be easily used with the event container as the template. Here is an example of how it can be defined:
@@ -978,25 +965,6 @@ When a network failure occurs and the space can't communicate with the client, t
 {{% include "/COM/notify-recovery.markdown" %}}
 
 
-# Triggering Notifications on Backup Instances
-
-By default notifications are replicated to backup instances but are not triggered. To enable notifications triggered also on backup instances the `cluster-config.groups.group.repl-policy.trigger-notify-templates` should be enabled. See below:
-
-
-```xml
-<os-core:embedded-space id="space" space-name="space" >	
-	<os-core:properties>
-		<props>
-			<prop key="cluster-config.groups.group.repl-policy.trigger-notify-templates">true</prop>
-		</props>
-	</os-core:properties>
-</os-core:space>
-```
-
-{{% note %}}
-When this option is enabled - When running collocated notify container the listener implementation should not access its collocated instance as this is blocked with backup instances.  
-{{%/note%}}
-
 # Durable Notifications
 
 Due-to the asynchronous nature of notification delivery, when a primary space fails right after replicating an operation to the backup space and before sending the notification to the registered client, the backup space might not be able to send the missing notifications, since it is in the process of moving to active mode.
diff --git a/site/content/xap/12.2/dev-java/notify-container.markdown b/site/content/xap/12.2/dev-java/notify-container.markdown
@@ -150,17 +150,6 @@ This may be observed with garbage created very quickly that may result in long p
 To avoid this behavior, the notify listener implementation should have [batching enabled](#batch-events) where minimal write/update/change/removal operations should be conducted, if any. 
 If the listener performs a large number of space operations, a [polling container](./polling-container.html#notify-verses-polling-container) should be considered, as this is a more controlled event handler.
 
-
-# Primary/Backup
-
-By default, the notify event container registers for notifications only when the relevant space against which it is working is in primary mode. When the space is in backup mode, no registration occurs. If the space moves from backup mode to primary mode, the container registers for notifications, and if it moved to backup mode, the registrations are canceled.
-
- This mostly applies when working with an embedded space directly with a cluster member. When working with a clustered space (performing operations against the whole cluster), the mode of the space is always primary.
- 
-{{% note "NOTIFY_LEASE_EXPIRATION"%}}
-Notifications for expired objects (NOTIFY_LEASE_EXPIRATION type) are sent both from the primary and the backup space. To avoid this, you should set the Notify Container `replicateNotifyTemplate` to `false` and run the notify container collocated with the space. This will start the Notify Container only with the primary and will avoid duplicated notifications.
-{{%/note%}}
-
 # Template Definition
 
 When performing receive operations, a template is defined, creating a virtualized subset of data in the space, matching it. XAP supports templates based on the actual domain model (with `null` values denoting wildcards), which are shown in the examples. XAP allows the use of [SQLQuery](./query-sql.html) in order to query the space, which can be easily used with the event container as the template. Here is an example of how it can be defined:
@@ -982,25 +971,6 @@ When a network failure occurs and the space cannot communicate with the client,
 {{% include "/COM/notify-recovery.markdown" %}}
 
 
-# Triggering Notifications on Backup Instances
-
-By default, notifications are replicated to backup instances but are not triggered. To enable also triggering notifications on backup instances, the `cluster-config.groups.group.repl-policy.trigger-notify-templates` should be enabled. See below:
-
-
-```xml
-<os-core:embedded-space id="space" space-name="space" >	
-	<os-core:properties>
-		<props>
-			<prop key="cluster-config.groups.group.repl-policy.trigger-notify-templates">true</prop>
-		</props>
-	</os-core:properties>
-</os-core:space>
-```
-
-{{% note "Note"%}}
-If this option is enabled, when running co-located notify containers the listener implementation should not access its co-located instance because it is blocked by the backup instances.  
-{{%/note%}}
-
 # Durable Notifications
 
 Due to the asynchronous nature of notification delivery, when a primary space fails right after replicating an operation to the backup space and before sending the notification to the registered client, the backup space might not be able to send the missing notifications, because it is in the process of moving to primary mode.
diff --git a/site/content/xap/12.3/dev-java/notify-container-overview.markdown b/site/content/xap/12.3/dev-java/notify-container-overview.markdown
@@ -146,16 +146,6 @@ This behavior should be avoided, as it may throttle the activity or impose large
 To prevent this, the notify listener implementation should have [batching enabled](#batch-events), where minimal write/update/change/removal operations should be conducted (if any). If the listener performs a large number of Space operations, a [polling container](./polling-container-overview.html#notify-verses-polling-container) should be considered, as this is a more controlled event handler.
 
 
-# Primary/Backup
-
-By default, the notify event container registers for notifications only when the relevant Space against which it is working is in primary mode. When the Space is in backup mode, no registration occurs. If the Space moves from backup mode to primary mode, the container registers for notifications, and if the Space moves to backup mode, the registrations are canceled.
-
-This behavior applies when working with an embedded Space directly with a cluster member. When working with a clustered Space (performing operations against the whole cluster), the mode of the Space is always primary.
- 
-{{% note "NOTIFY_LEASE_EXPIRATION"%}}
-Notifications for expired objects (NOTIFY_LEASE_EXPIRATION type) are sent both from the primary and the backup Spaces. To avoid duplicate notifications, set the Notify Container `replicateNotifyTemplate` to `false` and run the notify container co-located with the Space. This will start the Notify Container only with the primary, and prevent a duplicate notification scenario.
-{{%/note%}}
-
 # Template Definition
 
 When performing receive operations a template is defined, creating a virtualized subset of data in the Space that matches it. XAP supports templates based on the actual domain model (with `null` values denoting wildcards), which are shown in the examples. XAP allows the use of [SQLQuery](./query-sql.html) in order to query the Space, which can be easily used with the event container as the template. The following is an example of how it can be defined:
@@ -971,28 +961,6 @@ When a network failure occurs and the Space can't communicate with the client, t
 </os-core:embedded-space>
 ```
 
- 
-
-
-# Triggering Notifications on Backup Instances
-
-By default, notifications are replicated to backup instances but are not triggered. To trigger notifications on backup instances, enable `cluster-config.groups.group.repl-policy.trigger-notify-templates`. See below:
-
-
-```xml
-<os-core:embedded-space id="space" space-name="space" >	
-	<os-core:properties>
-		<props>
-			<prop key="cluster-config.groups.group.repl-policy.trigger-notify-templates">true</prop>
-		</props>
-	</os-core:properties>
-</os-core:space>
-```
-
-{{% note "Note"%}}
-If this option is enabled, when running co-located notify containers the listener implementation should not access its co-located instance, because it is blocked by the backup instances.  
-{{%/note%}}
-
 # Durable Notifications
 
 Due to the asynchronous nature of notification delivery, when a primary Space fails right after replicating an operation to the backup Space and before sending the notification to the registered client, the backup Space may not be able to send the missing notifications because it is in the process of moving to primary mode. As a result, during this very short period of time the registered client might not receive events that occurred in the primary Space and were replicated to the backup Space.
