You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The /api/log_entries/entries route issues several requests to Elasticsearch in order to efficiently fetch a chunk of log entries. The new point-in-time API in Elasticsearch can avoid timing-related inconsistencies in the results.
Background
In the requests the log entries are sorted by the timestamp and the _doc value as a tiebreaker. The latter can change when segments are merged by Elasticsearch, which can not be controlled or predicted by our code. If that happens while a client fetches a chunk of log entries via the above route the results might be incorrect. Specifically, the response might contain duplicate log entries or miss a arbitrarily large chunk of log entries.
With the newly added point-in-time API in Elasticsearch (elastic/elasticsearch#61062) we have the ability to request a consistent view on the indices for a short time. This would prevent such inconsistencies from occurring since the requests would all access the same stable set of segments.
This also applies to the requests made by the planned search strategy (#76677).
Acceptance criteria
The log entries adapter, which backs the log entries route at /api/log_entries/entries, uses the new point-in-time API to access a consistent view for the duration of the HTTP request.
The point-in-time state is created with an appropriate TTL.
The point-in-time state is properly cleaned up when the requests are finished (also on failure).
Summary
The
/api/log_entries/entries
route issues several requests to Elasticsearch in order to efficiently fetch a chunk of log entries. The new point-in-time API in Elasticsearch can avoid timing-related inconsistencies in the results.Background
In the requests the log entries are sorted by the timestamp and the
_doc
value as a tiebreaker. The latter can change when segments are merged by Elasticsearch, which can not be controlled or predicted by our code. If that happens while a client fetches a chunk of log entries via the above route the results might be incorrect. Specifically, the response might contain duplicate log entries or miss a arbitrarily large chunk of log entries.With the newly added point-in-time API in Elasticsearch (elastic/elasticsearch#61062) we have the ability to request a consistent view on the indices for a short time. This would prevent such inconsistencies from occurring since the requests would all access the same stable set of segments.
This also applies to the requests made by the planned search strategy (#76677).
Acceptance criteria
/api/log_entries/entries
, uses the new point-in-time API to access a consistent view for the duration of the HTTP request.Related links
The text was updated successfully, but these errors were encountered: