Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Infinite repeating discover (part 2)|
|Product:||[Other] RHQ Project||Reporter:||Greg Hinkle <ghinkle>|
|Component:||Plugin Container||Assignee:||RHQ Project Maintainer <rhq-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||1.4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-05-05 14:07:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Greg Hinkle 2009-03-31 01:41:00 EDT
Found a case where every time a service level scan was run it would cause a repeating scan to run because it thought one of the resources had been "modified". In point of fact, it seems that somehow I got two resources of type "filesystem" in with the same resourceKey (i.e. a duplicate resource). The outcome is that InventoryManager:1740 thinks that resource has been modified because its comparing the id of the first to the id of the duplicate. Perhaps a more bullet proof solution is to have a limit on the # of recursive calls to discovery reports so that they won't go for ever if inventory gets into somewhat messed up places. I've marked this as a minor as I don't know of anyone else who has gotten their inventory into this messed up state... likely pretty rare. And a workaround is to delete one of the resources.
Comment 1 Joseph Marques 2009-04-28 03:06:57 EDT
greg, can you try and re-run this scenario and see if it still happens for you. as part of the perf tuning we did for 1.2 release, the synchronization code between agents and server was relaxed. it was determined that we were notifying the agent that a resource had changed TOO often, which i have a strong feeling contributed to this infinite repeating discovery. if i'm right, you should not be able to reproduce this anymore.
Comment 2 Charles Crouch 2009-07-17 14:38:24 EDT
Look at RHQ-2057 for a similar issue of duplicated resources in the agent inv.