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

Drop jobs from Offline downstairs. #1157

Merged
merged 4 commits into from
Feb 14, 2024
Merged

Drop jobs from Offline downstairs. #1157

merged 4 commits into from
Feb 14, 2024

Conversation

leftwo
Copy link
Contributor

@leftwo leftwo commented Feb 12, 2024

If we receive a job ACK from an offline downstairs, and that job has already been moved
back to New, then discard it as we know the replay will resend it when the downstairs
comes back.

This is to fix #1155

If we receive a job ACK from an offline downstairs, and that job
has already been moved back to New, then discard it as we know
the replay will resend it when the downstairs comes back.
@leftwo leftwo requested a review from mkeeter February 12, 2024 16:56
@mkeeter
Copy link
Contributor

mkeeter commented Feb 12, 2024

I'm surprised that this isn't fixed by #1131: once the downstairs IO task stops, I would expect that we would have mismatches between DeferredMessage::connection_id and DownstairsClient::get_connection_id, and would therefore discard messages before hitting this point. We should never be seeing messages from an old connection; that's the whole point of #1131.

Looking into the code, I think the real issue is a race condition in DownstairsClient::get_connection_id. We only increment self.downstairs.clients[client_id].stats.connected after seeing ClientAction::Connected. This means that (terminated) connection N and (brand new) connection N + 1 will return the same value for get_connection_id, until connection N + 1 actually connects to the Downstairs.

I think the correct fix is to fix DownstairsClient::get_connection_id so that it rolls over immediately when a new connection is established (rather than relying on stats.connected). Let me know if that makes sense!

@@ -195,6 +195,9 @@ pub(crate) struct DownstairsClient {

/// State for startup negotiation
negotiation_state: NegotiationState,

/// Session ID for a clients connection to a downstairs.
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
/// Session ID for a clients connection to a downstairs.
/// Session ID for a clients connection to a downstairs.
///
/// This value is incremented whenever we restart the client IO task.

@mkeeter
Copy link
Contributor

mkeeter commented Feb 13, 2024

This looks much better, thanks!

My one remaining thought is wondering whether we should define a struct ConnectionId(u64), instead of the current usize (in DownstairsClient) → u64 (in get_connection_id)

@leftwo leftwo requested a review from mkeeter February 14, 2024 00:33
@leftwo
Copy link
Contributor Author

leftwo commented Feb 14, 2024

This looks much better, thanks!

My one remaining thought is wondering whether we should define a struct ConnectionId(u64), instead of the current usize (in DownstairsClient) → u64 (in get_connection_id)

I've done that in the last commit. I think this should be ready to go now.

@@ -2197,7 +2215,7 @@ impl DownstairsClient {
/// different connections to the same Downstairs.
pub(crate) fn get_connection_id(&self) -> Option<u64> {
if self.client_task.client_stop_tx.is_some() {
Some(self.connection_id as u64)
Some(self.connection_id.0)
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry to be so pedantic, but now that you've added the new type, we should actually use it – this function should be changed to return an Option<ConnectionId>, and then fix all of the compiler errors and we should be good :)

@leftwo leftwo merged commit 4105133 into main Feb 14, 2024
18 checks passed
@leftwo leftwo deleted the alan/offline-drop branch February 14, 2024 18:09
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.

Upstairs tries to process job after downstairs disconnects
2 participants