-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Ingest Manager] Better default value for fleet long polling timeout #76393
[Ingest Manager] Better default value for fleet long polling timeout #76393
Conversation
Pinging @elastic/ingest-management (Team:Ingest Management) |
// Set a timeout 3s before the real timeout to have a chance to respond an empty response before socket timeout | ||
Math.max((appContextService.getConfig()?.fleet.pollingRequestTimeout ?? 0) - 3000, 3000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean we can run into an edge case where the response can come in at almost the request time out limit? let's say 2 seconds before the limit. will this logic cause that to be ignored and treated as an empty response?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we can have an edge case here
The arbitrary 3s delay try to mitigate the risk of not sending any response (the way Kibana handle socket timeout the socket is destroyed immediately so we cannot send any data), but it can still happen if we some huge delay in the event loop.
If the response is happening like 2 seconds before the socket timeout we will send an empty response but it will be fixed during the next checkin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jen-huang let me know if I can still clarify that :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will be fixed during the next checkin
ah got it. that sounds acceptable to me 👍
* master: (340 commits) [data.search.SearchSource] Remove legacy ES client APIs. (elastic#75943) [release notes] automatically retry on Github API 5xx errors (elastic#76447) [es_ui_shared] Fix eslint exhaustive deps rule (elastic#76392) [i18n] Integrate 7.9.1 Translations (elastic#76391) [APM] Update aggregations to support script sources (elastic#76429) [Security Solution] Refactor Network Top Countries to use Search Strategy (elastic#76244) Document security settings available on ESS (elastic#76513) [Ingest Manager] Add input revision to the config send to the agent (elastic#76327) [DOCS] Identifies cloud settings for Monitoring (elastic#76579) [DOCS] Identifies Cloud settings in Dev Tools (elastic#76583) [Ingest Manager] Better default value for fleet long polling timeout (elastic#76393) [data.indexPatterns] Fix broken rollup index pattern creation (elastic#76593) [Ingest Manager] Split Registry errors into Connection & Response (elastic#76558) [Security Solution] add an excess validation instead of the exact match (elastic#76472) Introduce TS incremental builds & move src/test_utils to TS project (elastic#76082) fix bad merge (elastic#76629) [Newsfeed] Ensure the version format when calling the API (elastic#76381) remove server_extensions mixin (elastic#76606) Remove legacy applications and legacy mode (elastic#75987) [Discover] Fix sidebar element focus behavior when adding / removing columns (elastic#75749) ...
Summary
Resolve #75552
Increasing the long polling timeout allow Fleet to support a higher number of agents.
Done in this PR:
xpack.ingestManager.fleet.pollingRequestTimeout
. (so we can have a different timeout for Fleet than the rest of Kibana)