Description of problem: Looking at the git commit af61182448949a93472d4172210d4dbbe7f10f19 it seems the query added for taskomatic_uuid_cleanup was in the callable-mode vs write mode: diff --git a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Task_queries.xml b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Task_queries.xml index 3327de9..4ea777a 100644 --- a/java/code/src/com/redhat/rhn/common/db/datasource/xml/Task_queries.xml +++ b/java/code/src/com/redhat/rhn/common/db/datasource/xml/Task_queries.xml @@ -716,4 +716,14 @@ select sa.action_id, sa.server_id </query> </mode> +<callable-mode name="taskomatic_uuid_cleanup"> + <query> + delete + from rhnVirtualInstance + where virtual_system_id is NULL + and host_system_id is NULL + and uuid is not NULL + </query> +</callable-mode> Currently we are experiencing a hung taskomatic state when taskomatic runs this query. Looking at other delete queries in the Taskomatic datasource XML it appears this should probably be a write mode. Will be testing changing this to write mode for a customer and will include patch to this bz if hung state is fixed.
Created attachment 1215013 [details] patch to change to writemode datasource query
I think we need to dig deeper into this - while marking this mode-query as 'callable-' instead of 'write-mode' is incorrect, it shouldn't be fatal. If you compare the code of WriteMode and CallableMode, you can see they're both just convenience-classes on top of BaseMode, and both devolve into invocations of CachedStatement. Experimentation shows that using callable-mode where one means write-mode is largely harmless. We definitely want to take this patch - but I'll be surprised if it turns out to be "the problem" the customer is hiting.
I see this BZ as a request to accept the patch. The patch looks to be correct and I'm accepting it to upstream ... spacewalk.git: 2f18468f37315b63ff58d1d928cfb621f89c7ed0 Honestly I agree with Grant and do not believe this patch has any impact on taskomatic hung.