Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Batch subscriber #148

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Batch subscriber #148

wants to merge 1 commit into from

Conversation

fulmicoton
Copy link
Contributor

@fulmicoton fulmicoton commented Apr 30, 2024

Upon reset_node and apply_update, we want to be
able to react to a batch of changes rather than individual changes.

In quickwit for instance, we want to be able to react to the reception of a batch of deleted shard and group this reaction into a single metastore call.

@fulmicoton fulmicoton force-pushed the batch-subscriber branch 11 times, most recently from f09f842 to 6fdf427 Compare May 2, 2024 03:05
@fulmicoton fulmicoton requested a review from trinity-1686a May 2, 2024 03:05
@fulmicoton fulmicoton marked this pull request as ready for review May 2, 2024 04:43
@fulmicoton fulmicoton force-pushed the batch-subscriber branch 4 times, most recently from 2505843 to 0046e5a Compare May 2, 2024 13:34
Upon reset_node and apply_update, we want to be
able to react to a batch of changes rather than individual changes.

In quickwit for instance, we want to be able to react to the reception of a batch of deleted shard and group this reaction into a single metastore call.
Copy link
Contributor

@trinity-1686a trinity-1686a left a comment

Choose a reason for hiding this comment

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

i still have to read through half of state.rs. In the meantime, here are my first comments

let node_state = self.cluster_state.node_state_mut(chitchat_id);
) -> anyhow::Result<()> {
// We validate the version is compatible with what is in key_values.
if !key_values.is_empty() {
Copy link
Contributor

Choose a reason for hiding this comment

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

this check is redundant (if key_values is empty, the for will not iterate)

listener_idx: usize,
// Callbacks is a hashmap because as we delete listeners, we create "holes" in the
// callback_id -> callback mapping
callbacks: HashMap<usize, CallbackEntry>,
Copy link
Contributor

Choose a reason for hiding this comment

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

can you make this a HashMap<CallbackId, CallbackEntry> to make clear it goes hand in hand with listeners

NodeState {
chitchat_id,
heartbeat: Heartbeat(0),
key_values: Default::default(),
max_version: 0u64,
listeners,
// listeners,
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// listeners,

Comment on lines +783 to +796
impl<'a> Deref for NodeStateMut<'a> {
type Target = NodeState;

fn deref(&self) -> &NodeState {
self.node_state_mut
}
}

impl<'a> DerefMut for NodeStateMut<'a> {
fn deref_mut(&mut self) -> &mut NodeState {
self.node_state_mut
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I think deref makes sense, but deref_mut is bound to cause mutations which don't notify listeners

Comment on lines +902 to +904
key.to_string(),
VersionedValue {
value: value.to_string(),
Copy link
Contributor

Choose a reason for hiding this comment

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

these to_string() look redundant

Copy link
Contributor

@trinity-1686a trinity-1686a left a comment

Choose a reason for hiding this comment

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

(see also first batch)

Comment on lines +1184 to 1189
// 0 stale values
{
cluster_state.node_state_mut(&node5);
}

// 3 stale values
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand where the stale value count come from. Before node5 and node6 had respectively 3 and 0 (instead of 0 and 3) stale values. I don't see an obvious reason this changed

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