Skip to content

Conversation

original-brownbear
Copy link
Contributor

@original-brownbear original-brownbear commented May 15, 2022

No need to collect responses into an intermediary list, we can write them directly
as they become writable.
Also, we can be more efficient for the common case where the response written is of the
right sequence number and write it out directly.

follow up to #86133

No need to collect responses into an intermediary list, we can write them directly
as they become writable.
Also, we can be more efficient for the common case where the response written is of the
right sequence number and write it out directly.
@original-brownbear original-brownbear added >non-issue :Distributed Coordination/Network Http and internode communication implementations v8.3.0 labels May 15, 2022
@elasticmachine elasticmachine added the Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. label May 15, 2022
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

// response is at the current sequence number and does not need to wait for any other response to be written so we write
// it out directly
doWrite(ctx, response, promise);
success = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be set after the loop below?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No in fact I consciously moved it here. Once we resolve the promise in doWrite (which we will do one way or another) we must not touch it again, that would always be a bug.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add a test that provokes that failure and then see that it is fixed by this PR? Seems we do not have tests that verify that we do not double notify failures and we used to sometimes do so?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we can test this without creating an unrealistic situation. We should never be throwing here unless we exceed the outbound queue capacity to begin with. I really just fixed this as a cleanup to make it more obviously correct, unless we have a bug somewhere this doesn't change anything.

Copy link
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

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

LGTM.

if (response.getSequence() != writeSequence) {
if (outboundHoldingQueue.size() >= maxEventsHeld) {
int eventCount = outboundHoldingQueue.size() + 1;
throw new IllegalStateException(
Copy link
Contributor

Choose a reason for hiding this comment

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

This PR slightly changes semantics for when the queue is nearly full in that if the event that triggers that the queue is full has the right seq-no, it no longer fails. That sounds fine to me, but wanted to ensure other reviewers consider it.

// response is at the current sequence number and does not need to wait for any other response to be written so we write
// it out directly
doWrite(ctx, response, promise);
success = true;
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add a test that provokes that failure and then see that it is fixed by this PR? Seems we do not have tests that verify that we do not double notify failures and we used to sometimes do so?

@original-brownbear
Copy link
Contributor Author

Thanks Ievgen + Henning!

@original-brownbear original-brownbear merged commit 064029a into elastic:master May 16, 2022
@original-brownbear original-brownbear deleted the further-cleanup-rest-layer branch May 16, 2022 13:12
@original-brownbear original-brownbear restored the further-cleanup-rest-layer branch April 18, 2023 20:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed Coordination/Network Http and internode communication implementations >non-issue Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v8.3.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants