alievmirza commented on a change in pull request #724:
URL: https://github.com/apache/ignite-3/pull/724#discussion_r827664087
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
Review comment:
```suggestion
Every component registers configuration update listeners while starting.
These listeners receive notifications during the further lifetime of the node,
and also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of the order in which these listeners will be
called. It should be guaranteed by the causality tokens mechanism.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
Review comment:
> registers configuration update listeners
Lets add the link to the listeners mechanism, that is described in
`modules/runner/README.md` (`Node components startup` section)
> also during the recovery process
I would add here link to the recovery process mechanism Readme.
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
Review comment:
```suggestion
Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received a corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. The token should be taken from notification. The call to component
B now returns a future. This future is completed when component B receives
notifications that have a causality token in the context of which the future
was created. After completion of this future, the listener in component A can
continue working – of course, it should happen asynchronously.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
+
+More formally, one can make a call for a component using causality token and
receive a future, that will be completed when this component handles
notification about storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
Review comment:
```suggestion
More formally, one can make a call for a component using a causality token
and receive a future, that will be completed when this component handles
notification about a storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
+
+More formally, one can make a call for a component using causality token and
receive a future, that will be completed when this component handles
notification about storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
+
+This guarantees that notifications will be handled by component listeners in a
proper order.
Review comment:
```suggestion
This guarantees that notifications will be handled by component listeners in
the proper order.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
+
+More formally, one can make a call for a component using causality token and
receive a future, that will be completed when this component handles
notification about storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
Review comment:
It is not clear for me from the doc, what if component A waits for the
component B to handle some notification with causality token, but component B
hasn't registered any listener at all, won't be there an infinite waiting loop?
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
+
+More formally, one can make a call for a component using causality token and
receive a future, that will be completed when this component handles
notification about storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
+
+This guarantees that notifications will be handled by component listeners in a
proper order.
+
+It is also worth mentioning that local events should also be produced within a
context of an appropriate causality token.
Review comment:
```suggestion
It is also worth mentioning that local events should also be produced within
the context of an appropriate causality token.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
+
+Components’ listeners that process these notifications, can be called in any
order. So there may be a situation when a listener registered in component A
tries to call component B, but component B is not ready because its listeners
haven’t received corresponding notification yet. The listener of component A
needs to make sure that component B is in a consistent up-to-date state, so it
needs to await this state, and then continue the execution of a code dependent
on component B. It is achieved by including a causality token to a call to
component B. Token should be taken from notification. The call to component B
now returns a future. This future is completed when component B has received
notifications that have a causality token in context of which the future was
created. After completion of this future, the listener in component A can
continue working - of course, it should happen asynchronously.
+
+More formally, one can make a call for a component using causality token and
receive a future, that will be completed when this component handles
notification about storage revision update having the given causality token.
The result of this future should be guaranteed to be consistent regarding the
given token.
+
+This guarantees that notifications will be handled by component listeners in a
proper order.
+
+It is also worth mentioning that local events should also be produced within a
context of an appropriate causality token.
+
+### Versioned value
Review comment:
Could you please describe the reason why `Versioned value` concept was
introduced?
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
Review comment:
```suggestion
Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about a storage revision update.
```
##########
File path:
modules/core/src/main/java/org/apache/ignite/internal/causality/README.md
##########
@@ -0,0 +1,27 @@
+This package contains classes that are used for implementation of
functionality based on causality tokens.
+
+### The purpose
+
+Every component registers configuration update listeners while starting. These
listeners receive notifications during the further lifetime of the node, and
also during the recovery process while retrieving notifications from
Metastorage. While handling the notifications, listeners should rely on the
fact that the components that they depend on, won’t return stale or
inconsistent data, regardless of order in which these listeners will be called.
It should be guaranteed by causality tokens mechanism.
+
+### Causality tokens
+
+Cluster-wide events, such as, for example, configuration changes or
Metastorage updates, trigger notifications that are propagated to the nodes and
therefore, to components. Every event can trigger one or several notifications.
Every notification has a causality token. Notifications triggered by the same
event have the same causality token. It is guaranteed that the last
notification produced with a certain causality token, will be a notification
about storage revision update.
Review comment:
Also I would add here link to the `Reliable watch processing` section
from `modules/runner/README.md `
Concept of the `storage revision update` should be described also
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
