Branch: refs/heads/master
Home:
https://github.com/rhq-project/rhq
Commit: 3e47741694b55fedecf9c904d89de11a7b92ccb2
https://github.com/rhq-project/rhq/commit/3e47741694b55fedecf9c904d89de11...
Author: Jay Shaughnessy <jshaughn(a)redhat.com>
Date: 2014-07-24 (Thu, 24 Jul 2014)
Changed paths:
M modules/core/domain/src/main/java/org/rhq/core/domain/resource/Resource.java
M
modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/InventoryManager.java
M
modules/core/plugin-container/src/main/java/org/rhq/core/pc/inventory/RuntimeDiscoveryExecutor.java
Log Message:
-----------
[801432, 807465] Related Issue to these BZs
Uninventory triggered our "assert-style" debug logging indicating that we
were working with HashSet for child resources when we expected to be using
a safer Set impl (wrt preventing ConcurrentModoficationException). There
were a few issues in play:
- When loading persisted resources from disk convert childResources to
CopyOnWriteArraySet if necessary. This repairs resources persisted with
the wrong Set impl.
- Eliminate some potential concurrent modification danger (or, at a minimum,
- Fix a couple of other places where we weren't using CopyOnWriteArraySet
- Fix Resource entity to ensure that when customChildResourcesCollection=true
that the childResources Set is truly protected. It was here that we were
losing the proper Set impl.
some unnecessary work) by only calling deactivateResource() on the root
resource. It recursively deactivates the subtree, so no need to then call
it on every node in the subtree.
- Fix our "assert-logging" conditional, which despite finding this issue was
actually looking for the wrong set impl. It had not been updated when we
moved to CopyOnWriteArraySet.