Skip to content

Improve notifications - #77

Open
rustybee42 wants to merge 2 commits into
mainfrom
rb/dont-wait-for-notifications
Open

Improve notifications#77
rustybee42 wants to merge 2 commits into
mainfrom
rb/dont-wait-for-notifications

Conversation

@rustybee42

Copy link
Copy Markdown
Collaborator

@rustybee42
rustybee42 requested a review from philippfalk August 13, 2026 09:54
@rustybee42 rustybee42 self-assigned this Aug 13, 2026
@rustybee42
rustybee42 requested a review from a team as a code owner August 13, 2026 09:54
* Don't wait for sending out notifications in update_node() and
map_target() as server nodes only have a one second timeout before they
consider registration failed. In some systems, apparently dumping the
udp messages takes longer than that.
* Improve send_notifications() to only do one db query, not multiple,
and call broadcast_datagram() only once.
* Improve notification trace logging
@rustybee42
rustybee42 force-pushed the rb/dont-wait-for-notifications branch from 89ffbcd to cd4f610 Compare August 13, 2026 10:38

@philippfalk philippfalk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good for the most part. I had some trouble understanding the new tracker mechanism which was partly caused by a misleading comment.

Comment on lines +41 to +42
/// Creates a peak concurrency tracker object including the required atomics. Each invocation gets
/// its own tracker / atomics.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: I think this comment is slightly misleading. "Each invocation" implies that every time this is encountered in the code new atomics are created. That's not true because the atomics are declared static (which makes this work) and because this is a macro, "expansion" would actually be more accurate than "invocation".

Suggested change
/// Creates a peak concurrency tracker object including the required atomics. Each invocation gets
/// its own tracker / atomics.
/// Creates a peak concurrency tracker object including the required atomics. Each expansion site
/// gets its own tracker / atomics.

Comment thread mgmtd/src/app/runtime.rs
// to catch a potential bottleneck here on big systems.
let concurrency_tracker = peak_concurrency_tracker!();
if let Some(peak) = concurrency_tracker.peaked() {
log::info!("Concurrent notifications peaked at {peak}",);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Is info the correct log level here? At least initially, this will be logged quite a number of times as the counter increments. I believe the default log level is warn, so this will not log by default, but this could also be considered debug information.

MetaRoot::Unknown => 0,
MetaRoot::Normal(node_id, _) => node_id,
MetaRoot::Mirrored(group_id) => group_id.into(),
// Don't wait for notifications to go out because server nodes only waits for a short time for

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Don't wait for notifications to go out because server nodes only waits for a short time for
// Don't wait for notifications to go out because server nodes only wait for a short time for

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants