[checkmk-commits] [Checkmk/checkmk] fe46d1: initial commit of RabbitMQ config

Branch: refs/heads/master Home: https://github.com/Checkmk/checkmk Commit: fe46d1b82362c8c855d38be4b1990e4b939b294f https://github.com/Checkmk/checkmk/commit/fe46d1b82362c8c855d38be4b1990e4b9… Author: Moritz Kiemer <moritz.kiemer(a)checkmk.com> Date: 2024-07-16 (Tue, 16 Jul 2024) Changed paths: A omd/packages/rabbitmq/skeleton/etc/rabbitmq/conf.d/00-default.conf A omd/packages/rabbitmq/skeleton/etc/rabbitmq/definitions.d/00-default.json Log Message: ----------- initial commit of RabbitMQ config Change-Id: Idc2f82e22c6d8eef9154dd752a1382bbbc9a6f23 Commit: 578eb23eb54dfed5b225c2bb3b77685337b89938 https://github.com/Checkmk/checkmk/commit/578eb23eb54dfed5b225c2bb3b7768533… Author: Lars Michelsen <lm(a)checkmk.com> Date: 2024-07-16 (Tue, 16 Jul 2024) Changed paths: M cmk/gui/background_job/_base.py Log Message: ----------- Fix background job startup timing issues When the job inizializaion took more than 5 seconds, the job status (get_status, is_active) could report a not running process while the job is still being started. This lead to various waiting routines, like waiting for a host renaming background job via the REST API, to finish too early. Details: The startup roughly works like this: 1. Spawn a new python process. 2. Multiprocessing hands over to our run_process function. 3. The run_process function sets the *thread title* of the process. 4. The jobs business logic is being executed. The thread title plays an important role in the identifcation of the process to prevent issues with PID reuse. When other processes ask for the state of the job, we check whether a process with the same PID is still running. Then we check whether the thread title is as expected to ensure that we are working with the right process. However, when the job is still being started as in 1. to 3. above, the thread title is not yet set. To handle this situation we had a 5 seconds grace period in place where we would not check the thread title and assume the process to be the right one. This logic does not work when the job initialization takes longer than 5 seconds. This change now tries to get rid of the timing issue by replacing the 5 second grace period with some kind of finger printing on the process which is only applied in the initialization phase of the process. This is not 100% bullet proof but is hopefully good enough for our use case. CMK-18295 Change-Id: I2dd5536106006f847760624953568734cecd0942 Compare: https://github.com/Checkmk/checkmk/compare/41c362a4f78b...578eb23eb54d To unsubscribe from these emails, change your notification settings at https://github.com/Checkmk/checkmk/settings/notifications