« Changelog History


ArangoDB v3.4.0-rc.5 Release Notes

Release Date: 2018-11-29 // over 5 years ago

    • 0️⃣ Persist and check default language (locale) selection. Previously we would not check if the language (--default-language) had changed when the server was restarted. This could cause issues with indexes over text fields, as it will resulted in undefined behavior within RocksDB (potentially missing entries, corruption, etc.). Now if the language is changed, ArangoDB will print out an error message on startup and abort.

    • 🛠 fixed issue #7522: FILTER logic totally broke for my query in 3.4-rc4

    • export version and storage engine in _admin/cluster/health for Coordinators and DBServers.

    • 🏗 restrict the total amount of data to build up in all in-memory RocksDB write buffers by default to a certain fraction of the available physical RAM. This helps restricting memory usage for the arangod process, but may have an effect on the RocksDB storage engine's write performance.

    In ArangoDB 3.3 the governing configuration option --rocksdb.total-write-buffer-size had a default value of 0, which meant that the memory usage was not limited. ArangoDB 3.4 now changes the default value to about 50% of available physical RAM, and 512MiB for setups with less than 4GiB of RAM.

    • 0️⃣ lower default value for --cache.size startup option from about 30% of physical RAM to about 25% percent of physical RAM.

    • 🛠 fix internal issue #2786: improved confirmation dialog when clicking the truncate button in the web UI

    • ⚡️ Updated joi library (web UI), improved Foxx mount path validation

    • 🐧 disable startup warning for Linux kernel variable vm.overcommit_memory settings values of 0 or 1. Effectively overcommit_memory settings value of 0 or 1 fix two memory-allocation related issues with the default memory allocator used in ArangoDB release builds on 64bit Linux. The issues will remain when running with an overcommit_memory settings value of 2, so this is now discouraged. Setting overcommit_memory to 0 or 1 (0 is the Linux kernel's default) fixes issues with increasing numbers of memory mappings for the arangod process (which may lead to an out-of-memory situation if the kernel's maximum number of mappings threshold is hit) and an increasing amount of memory that the kernel counts as "committed". With an overcommit_memory setting of 0 or 1, an arangod process may either be killed by the kernel's OOM killer or will die with a segfault when accessing memory it has allocated before but the kernel could not provide later on. This is still more acceptable than the kernel not providing any more memory to the process when there is still physical memory left, which may have occurred with an overcommit_memory setting of 2 after the arangod process had done lots of allocations.

    In summary, the recommendation for the overcommit_memory setting is now to set it to 0 or 1 (0 is kernel default) and not use 2.

    • 🛠 fixed Foxx complaining about valid $schema value in manifest.json

    • 🛠 fix for supervision, which started failing servers using old transient store

    • 🛠 fixed a bug where indexes are used in the cluster while still being built on the db servers

    • 🛠 fix move leader shard: wait until all but the old leader are in sync. This fixes some unstable tests.

    • cluster health features more elaborate agent records

    • agency's supervision edited for advertised endpoints