[RFC][Search] Background sessions RFC #69117
Conversation
lizozom
added
Feature:Search
|
Pinging @elastic/kibana-app-arch (Team:AppArch) |
lizozom
added
backport:skip
| The main component of this RFC is the background session service. | ||
|
|
||
| It is a server side service, that tracks and stores sessions and all associated requests. | ||
| When a user starts executing a session, the service stores information in memory, until the user decides to "Send to Background" or until the expiration time. |
There was a problem hiding this comment.
Will this happen over multiple HTTP requests? When Kibana is deployed behind a load-balancer in a highly-available deployment, multiple HTTP requests will likely be served by multiple different instances of Kibana with different "memory".
There was a problem hiding this comment.
There will be one saved object, but multiple servers may be updating the saved object (depending on where search requests are routed).
| The main component of this RFC is the background session service. | ||
|
|
||
| It is a server side service, that tracks and stores sessions and all associated requests. | ||
| When a user starts executing a session, the service stores information in memory, until the user decides to "Send to Background" or until the expiration time. |
There was a problem hiding this comment.
I believe that at least some aspect of background sessions will be "per user", how will these be persisted?
There was a problem hiding this comment.
We'll store a hash of the username in the saved object itself, which we will use to filter the list we display to the user. While the saved objects themselves will be persisted to the user's space, we don't anticipate that to be an issue since we're storing a hash of the request/search IDs, not the search results themselves.
|
Replaced by #73281 |
4 participants
Summary
Summarize your PR. If it involves visual changes include a screenshot or gif.
Checklist
Delete any items that are not applicable to this PR.
For maintainers