diff --git a/site/content/xap/12.0/dev-java/notify-container.markdown b/site/content/xap/12.0/dev-java/notify-container.markdown index d05585876..902130271 100644 --- 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 - - - - true - - - -``` - -{{% 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 index d6b24e287..259515ace 100644 --- 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 - - - - true - - - -``` - -{{% 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 index 24fbe0c52..ffabb22d4 100644 --- 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 - - - - true - - - -``` - -{{% 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 index a963b69c1..12cbd3a4c 100644 --- 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 ``` - - - -# 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 - - - - true - - - -``` - -{{% 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.