Go to file
bors[bot] 8bc7dd8b03
Merge #143
143: Shared update store r=irevoire a=MarinPostma

This PR changes the updates process so that only one instance of an update store is shared among indexes.

This allows updates to always be processed sequentially without additional synchronization, and fixes the bug where all the first pending update for each index were reported as processing whereas only one was.

EDIT:

I ended having to rewrite the whole `UpdateStore` to allow updates being really queued and processed sequentially in the ordered they were added. For that purpose I created a `pending_queue` that orders the updates by a global update id.

To find the next `update_id` to use, both globally and for each index, I have created another database that contains the next id to use.

Finally, all updates that have been processed (with success or otherwise) are all stores in an `updates` database.

The layout for the keys of these databases are such that it is easy to iterate over the elements for a particular index, and greatly reduces the amount of code to do so, compared to the former implementation.

I have also simplified the locking mechanism for the update store, thanks to the StateLock data structure, that allow both an arbitrary number of readers and a single writer to concurrently access the state. The current state can be either Idle, Processing, or Snapshotting. When an update or snapshotting is ongoing, the process holds the state lock until it is done processing its task. When it is done, it sets bask the state to Idle.

I have made other small improvements here and there, and have let some other for work, such as:
- When creating an update file to hold a request's content, it would be preferable to first create a temporary file, and then atomically persist it when we have written to it. This would simplify the case when there is no data to be written to the file, since we wouldn't have to take care about cleaning after ourselves.
- The logic for content validation must be factored.
- Some more tests related to error handling in the process_pending_update function.
- The issue #159

close #114


Co-authored-by: Marin Postma <postma.marin@protonmail.com>
2021-04-27 18:41:55 +00:00
.github Update CI 2021-04-27 12:43:00 +02:00
meilisearch-error serve static site 2021-04-22 10:26:54 +02:00
meilisearch-http Merge #143 2021-04-27 18:41:55 +00:00
.dockerignore add docker recipe 2021-03-01 14:41:57 +01:00
.gitignore put mini-dashboard in out-dir 2021-04-27 09:32:17 +02:00
bors.toml Update CI 2021-04-27 12:43:00 +02:00
Cargo.lock fix clippy warnings 2021-04-27 18:28:46 +02:00
Cargo.toml create workspace with meilisearch-error 2021-03-01 14:41:55 +01:00
Dockerfile review fixes 2021-04-26 10:20:46 +02:00
LICENSE add license 2021-02-28 10:08:36 +01:00
README.md Update README.md 2021-04-27 16:33:22 +02:00

Transplant

Transplant makes communication between the users and Milli using HTTP. The final purpose of Transplant is to be merged into the current MeiliSearch repository so that users will enjoy the new search engine performance provided by Milli.

Run the alpha releases

Currently only alpha versions are available.

You can:

  • Run it with Docker, for instance:
docker run -p 7700:7700 getmeili/meilisearch:v0.21.0-alpha.4 ./meilisearch
cargo run --release

Run the tests

cargo test

If you encounter any Too many open files error when running the tests, please upgrade the maximum number of open file descriptors with this command:

ulimit -Sn 3000