Skip to content

Run throttled fetches later instead of dropping them - #67

Open
CryLegende wants to merge 1 commit into
Azuriom:masterfrom
CryLegende:queue-throttled-fetch
Open

CryLegende wants to merge 1 commit into
Azuriom:masterfrom
CryLegende:queue-throttled-fetch

Conversation

@CryLegende

Copy link
Copy Markdown

A fetch requested less than 5 seconds after the previous one is dropped. When that's the ping from the website, the website gets a 200 but the queued commands just sit there until the next scheduled fetch, up to a minute later.

On our server that's about 1 vote out of 10 delivered more than 5 seconds late, and 1 out of 20 more than 30 seconds late.

Now the fetch is scheduled for the end of the 5 seconds instead of being dropped. There's still at most one request every 5 seconds, and the scheduled task skips its run if a request just went out.

Tested on DivineMC 26.3 with a local Azuriom site: commands queued 2 seconds after a fetch now arrive 3 seconds later, and 10 pings in a row only add one request. I haven't tried it on a proxy. ./gradlew :azlink-common:test passes.

This overlaps with #66: with this PR, its FetcherTask change is no longer needed.

A fetch requested less than 5 seconds after the previous request was
ignored. When it came from the website's instant commands request, the
commands stayed queued until the next scheduled fetch, up to one minute
later, even though the website had been told the request succeeded.

Schedule a single fetch for the end of the interval instead, so the rate
limit is unchanged and instant commands wait 5 seconds at most.
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.

1 participant