Resolve correctly when dictionary depends on dictionary#4962
Conversation
85703f1 to
8d7e228
Compare
e931ab4 to
060e453
Compare
406d28b to
6faa4ec
Compare
There was a problem hiding this comment.
Discussed that here we will wait until all dictionaries will be reloaded (in case ExternalLoader::reload() was called).
There was a problem hiding this comment.
I replaced all_mutex.lock() with all_mutex.try_lock() here, seems it's enough to fix this problem.
49e8ebb to
4645086
Compare
4645086 to
39c7107
Compare
| /// the current version of this loadable object. That's why we use try_lock() instead of lock() here. | ||
| std::unique_lock all_lock{all_mutex, std::defer_lock}; | ||
| if (all_lock.try_lock()) | ||
| finishReload(name, throw_on_error); |
There was a problem hiding this comment.
Looks like if no other thread which is reloading dictionaries, we will wait. (It's not true).
May be just check that dictionaries have loaded once?
Or first check that dictionary is not in loadable_objects, and then try lock.
There was a problem hiding this comment.
try_lock() never waits, it never blocks the current thread. If all_mutex is locked by another thread try_lock() just returns false without blocking.
There was a problem hiding this comment.
Yes. It just looks like in case no other thread locks all_mutex, and we successfully locked, all dictionaries will be reloading.
There was a problem hiding this comment.
Ok, successful lock is only possible in updating thread. Probably, your solution is better. (system reload dictionary will also resolve dependences fine)
…dictionary Resolve correctly when dictionary depends on dictionary (cherry picked from commit f0c7e56)
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Fix hanging on start of the server when a dictionary depends on another dictionary via a database with engine=Dictionary.
#4695
Category: