Hello,
when constantly sending new data via attrd the changes are never used.
Example:
while sleep 1
do attrd_updater -l reboot -d 5 -n rep_chg -U try$SECONDS
cibadmin -Ql | grep rep_chg
done
This always returns the same value - the one that was given with more than 5
seconds delay afterwards, so that the dampen interval wasn't broken by the
next change.
I've attached two draft patches; one for allowing the _first_ value in a
dampen interval to be used (effectively ignoring changes until this value is
written), and one for using the _last_ value in the dampen interval (by not
changing the dampen timer). [1]
*** Note: they are for discussion only!
*** I didn't test them, not even for compilation.
Perhaps this "bug" [2] was introduced with one of these changes (the hashes
are the GIT numbers)
High: crmd: Bug lf#2528 - Introduce a slight delay when
creating a transition to allow attrd time to perform its updates
e7f5da92490844d190609931f434e08c0440da0f
Low: attrd: Indicate when attrd clients are updating fields
69b49b93ff6fd25ac91f589d8149f2e71a5114c5
What is the correct way to handle multiple updates within the dampen
interval?
Thank you for any hints or ideas.
Regards,
Phil
Ad [1]: I even tried to provide an average, median or some other value here;
but a) this isn't necessarily valid (for boolean or integer values), and b)
as the data gets stored and transmitted as string it wouldn't easily work
anyway.
So the question remaining is just first or last value, IMO.
Ad [2]: if this _is_ a bug -- but I'd certainly argue that way, as _not_
propagating a change is worse than a changing value.
when constantly sending new data via attrd the changes are never used.
Example:
while sleep 1
do attrd_updater -l reboot -d 5 -n rep_chg -U try$SECONDS
cibadmin -Ql | grep rep_chg
done
This always returns the same value - the one that was given with more than 5
seconds delay afterwards, so that the dampen interval wasn't broken by the
next change.
I've attached two draft patches; one for allowing the _first_ value in a
dampen interval to be used (effectively ignoring changes until this value is
written), and one for using the _last_ value in the dampen interval (by not
changing the dampen timer). [1]
*** Note: they are for discussion only!
*** I didn't test them, not even for compilation.
Perhaps this "bug" [2] was introduced with one of these changes (the hashes
are the GIT numbers)
High: crmd: Bug lf#2528 - Introduce a slight delay when
creating a transition to allow attrd time to perform its updates
e7f5da92490844d190609931f434e08c0440da0f
Low: attrd: Indicate when attrd clients are updating fields
69b49b93ff6fd25ac91f589d8149f2e71a5114c5
What is the correct way to handle multiple updates within the dampen
interval?
Thank you for any hints or ideas.
Regards,
Phil
Ad [1]: I even tried to provide an average, median or some other value here;
but a) this isn't necessarily valid (for boolean or integer values), and b)
as the data gets stored and transmitted as string it wouldn't easily work
anyway.
So the question remaining is just first or last value, IMO.
Ad [2]: if this _is_ a bug -- but I'd certainly argue that way, as _not_
propagating a change is worse than a changing value.
