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

fix: Ensure that most TableListener/MergedListener Notifications are processed while ensuring liveness; improve timeout handling in Table.awaitUpdate #6422

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

rcaudy
Copy link
Member

@rcaudy rcaudy commented Nov 22, 2024

No description provided.

@rcaudy rcaudy added query engine core Core development tasks NoDocumentationNeeded ReleaseNotesNeeded Release notes are needed labels Nov 22, 2024
@rcaudy rcaudy requested a review from cpwright November 22, 2024 23:14
@rcaudy rcaudy self-assigned this Nov 22, 2024
@rcaudy rcaudy changed the title Ensure that most TableListener/MergedListener Notifications are processed while ensuring liveness; improve timeout handling in Table.awaitUpdate fix: Ensure that most TableListener/MergedListener Notifications are processed while ensuring liveness; improve timeout handling in Table.awaitUpdate Nov 22, 2024
rcaudy and others added 5 commits November 22, 2024 23:23
…ow run the actual notification processing work while guaranteeing that they remain live for the duration
… TimeSeriesFilters from previous validation rounds
…e don't report spurious double-notifies if a notification runs after destroy caused a prior notification to be skipped
@rcaudy rcaudy force-pushed the rwc-listenerliveness branch from 8e7117b to f28e9e2 Compare November 23, 2024 04:23
@rcaudy rcaudy added this to the 0.38.0 milestone Nov 23, 2024
return false;
}
timeoutMillis -= TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime, TimeUnit.NANOSECONDS);

Copy link
Contributor

Choose a reason for hiding this comment

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

I would check for timeoutMillis <= 0 and bail (or clamp it). I see no javadoc for the await call on Condition, but the standard wait call has the note:
In all respects, this method behaves as if wait(0L, 0) had been called. See the specification of the wait(long, int) method for details.

That has bit some of the Enterprise gRPC timeout handling in the past.

Which points out that if you have a zero argument, you are going to wait forever. I would prefer to have a check within the try to be very explicit about that edge case.

@rcaudy rcaudy marked this pull request as draft December 21, 2024 17:29
@rcaudy
Copy link
Member Author

rcaudy commented Dec 21, 2024

Back to draft/WIP, trying to expand the awaitUpdate work a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Core development tasks NoDocumentationNeeded query engine ReleaseNotesNeeded Release notes are needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants