Skip to content

Commit

Permalink
DOC-383 Removed two sections from Notify Container topic
Browse files Browse the repository at this point in the history 
Primary/Backup section, Triggering notification on backup instances section
  • Loading branch information
@PeninaR
PeninaR committed Jul 1, 2018
1 parent b7873ec commit 1f494af
Show file tree
Hide file tree
Showing 4 changed files with 0 additions and 126 deletions.
32 changes: 0 additions & 32 deletions site/content/xap/12.0/dev-java/notify-container.markdown
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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.
Expand Down
32 changes: 0 additions & 32 deletions site/content/xap/12.1/dev-java/notify-container.markdown
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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.
Expand Down
30 changes: 0 additions & 30 deletions site/content/xap/12.2/dev-java/notify-container.markdown
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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.
Expand Down
32 changes: 0 additions & 32 deletions site/content/xap/12.3/dev-java/notify-container-overview.markdown
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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.
Expand Down

0 comments on commit 1f494af

Please sign in to comment.