Share all details about your problem, including any error messages you may have received.
After a recent upgrade to IdentityIQ 8.5 Patch 1 we are seeing a significant uptick in tasks failures related to already running tasks. We have many hourly / daily tasks which are scheduled to run, and after the upgrade to 8.5 we see the hourly tasks being executed on both tasks servers in our cluster. One is successful, the other fails with an exception that “Unable to create qualified task result: due to already executing task”.
@kevinwoodbury Could you please try running the task in the specific host? Just to understand if the issue is with clustering or task management or something else.
Please confirm if you have Concurrent Execution enabled for Perform Maintenance task? Also review ServiceDefinition objects to make sure it is available as per 8.5p1 v.
@kevinwoodbury - Follow this steps to resolve your issue:
Ensure that your Perform Maintenance task and any other relevant hourly tasks do not have Allow Concurrent Execution ticked this could be triggered by this patch and would disable the safeguard designed to protect against the duplicate launch.
Make sure that your ServiceDefinition objects (especially TaskService and Heartbeat/RequestService) match the 8.5p1 setup if any of those services have customized overrides defined, patch import may ignore these files and will fail to update the cluster coordination.
As a temporary workaround until you identify the root cause: assign a specific server to these potentially conflicting tasks.
Thanks Kannan! Was there a change between 8.4 and 8.5 in terms of the ServiceDefinition objects? New Settings / etc? We have custom files we import during our build process as we have specific hosts listed in these files.
@kevinwoodbury - Unfortunately, I could not find anything in the release notes or product documentation pertaining to a change in either the ServiceDefinition schema or configuration setting in v8.5.
My recommendation is that you compare the hosts attribute on both definitions. If the hosts attribute now contains “global” (or both nodes) and not the actual host that you configured before, then obviously, your custom scoping got overridden during the process of importing the patch.
If you have not done so already, it would be worthwhile for you to re-import your custom host-specific ServiceDefinition XML file after patching.
Have you tried this in your lower environment?
In addtion can you share me your custom host specification and the error logs?
@kevinwoodbury Deploy the vanilla version of 8.5p1 and this will give you the standard objects. Now compare this with your customized objects that you have in your environment. This should tell you if you have missed out any critical item.
