-
Notifications
You must be signed in to change notification settings - Fork 8.6k
caching or versioning problem with multiple Kibana instances #7055
Copy link
Copy link
Closed
Labels
Feature:uiSettingsTeam:SharedUXPlatform AppEx-SharedUX (formerly Global Experience) t//Platform AppEx-SharedUX (formerly Global Experience) t//bugFixes for quality problems that affect the customer experienceFixes for quality problems that affect the customer experienceimpact:needs-assessmentProduct and/or Engineering needs to evaluate the impact of the change.Product and/or Engineering needs to evaluate the impact of the change.loe:smallSmall Level of EffortSmall Level of Effort
Metadata
Metadata
Assignees
Labels
Feature:uiSettingsTeam:SharedUXPlatform AppEx-SharedUX (formerly Global Experience) t//Platform AppEx-SharedUX (formerly Global Experience) t//bugFixes for quality problems that affect the customer experienceFixes for quality problems that affect the customer experienceimpact:needs-assessmentProduct and/or Engineering needs to evaluate the impact of the change.Product and/or Engineering needs to evaluate the impact of the change.loe:smallSmall Level of EffortSmall Level of Effort
Type
Fields
Give feedbackNo fields configured for issues without a type.
If you have 2 or more instances of Kibana sharing the same .kibana index, they can clobber each other's changes with values they have in cache.
To Reproduce;
#1on port 5601 and#2on port 5602 on the same machine.#1change discover:sampleSize (Default: 500) to 499#2change discover:sampleSize (Default: 500) to 501#1change courier:maxSegmentCount (Default: 30) to 29Expected discover:sampleSize (Default: 500) to be 501 since it was the last change made to that setting.
Actual discover:sampleSize (Default: 500) to 499 (probably because
#1had 499 cached when it wrote the courier:maxSegmentCount so it wrote the whole config object)If possible, it should know the version of the config object it has cached.
When it tries to write the object it should check the version first and, if later, show the user an error if it is a later version, and refresh the page to show the current version. The user can try to save again, or has to make their change again and save again.
OR
When it tries to write the object it should check the version first and, if later, get the latest version and re-apply the change and try to save it again (again checking the version).
OR
When it tries to write the object the write should include the next version and fail if that version already exist in Elasticsearch? Not sure which of these functionalities is possible. Then handle the error by getting the latest version, and re-applying the change. This could be the best performing solution because it only takes one round-trip in most cases.