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

Various improvements to CyclicTimeouts. #9897

Merged
merged 1 commit into from
Jun 10, 2023

Conversation

sbordet
Copy link
Contributor

@sbordet sbordet commented Jun 10, 2023

  • Improved reset of the earliest timeout before iteration.
  • Removed check for getExpireNanoTime() == -1, since it's a valid value.
  • When onExpired(Expirable) returns false, the Expirable should arrange to move its timeout in the future.

* Improved reset of the earliest timeout before iteration.
* Removed check for getExpireNanoTime() == -1, since it's a valid value.
* When onExpired(Expirable) returns false, the Expirable should arrange to move its timeout in the future.

Signed-off-by: Simone Bordet <[email protected]>
@sbordet sbordet requested a review from gregw June 10, 2023 13:36
@sbordet sbordet merged commit df24485 into jetty-12.0.x Jun 10, 2023
@sbordet sbordet deleted the fix/jetty-12-cyclictimeouts-improvements branch June 10, 2023 15:02
sbordet added a commit that referenced this pull request Feb 5, 2024
…en a server times out

Fixed regression introduced with #9897.
After onExpire() returns false, the entity is asked again the expirationNanoTime, but there was no check whether it was Long.MAX_VALUE, indicating that the entity should not be rescheduled.

This was causing scheduling of timeouts far in the future (about Long.MAX_VALUE nanos away), but each at a slightly different time, causing the leak.

Signed-off-by: Simone Bordet <[email protected]>
sbordet added a commit that referenced this pull request Feb 5, 2024
…en a server times out

Fixed regression introduced with #9897.
After onExpire() returns false, the entity is asked again the expirationNanoTime, but there was no check whether it was Long.MAX_VALUE, indicating that the entity should not be rescheduled.

This was causing scheduling of timeouts far in the future (about Long.MAX_VALUE nanos away), but each at a slightly different time, causing the leak.

Signed-off-by: Simone Bordet <[email protected]>
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