rhq-project/rhq — pull request #32 by metlos (2014-05-12 21:49:42+00:00)
Title: [BZ 1096332] Make sure ResourceContexts are fully inited on the agent

This fixes the broken "create child" and "content facet" deployment as well as other possibly yet undiscovered problems caused by the incomplete initialization of the resource contexts.

The fix is very simple. So much so that I fear of something more subtle biting us later on.
Please review with sharp eyes, I do think that especially the concurrent access from various scheduled jobs, if possible, could make for wonderful headaches.

Below is the commit message with the full description of the problem:

During InventoryManager initialization we do a lot of work including
activation and initialization of the resource containers and syncing
with the server for the purpose of resource activation and upgrade.

The initialization of the InventoryManager is done early in the
plugin container startup when most of the other services are not yet
available. But because we need a (sort of) functional inventory and
resource components DURING the inventory manager initialization, we
cheat a bit leaving some parts of the ResourceContext non-functional
during InventoryManager initialization. This has been made more serious
by the RFE BZ 991149 (commit 79a09a0a5a5402539f7a54668813f60ba274ce5a)
that made a lot of the initialization code more eager.

This fix is not much more but a band-aid providing a new "recovery
logic" to reinitialize all the resource containers and their resource
contexts once the initialization of all the plugin container services
is finished. This ensures proper initialization of all the parts of
the resource contexts AFTER the plugin containers is fully started up
but doesn't solve the problem of non-functional "parts" of resource
contexts during the resource upgrade phase (which is done during the
start up sequence). Granted this has not been proven to be an issue
yet, because the upgrade logic is usually very simple and doesn't
really need to access the parts of the resource context that are
affected by this (ATM I know of Content and Drift subsystems being
malfunctioning during the resource upgrade phase).

So in another words, this band-aid restores the proper functionality
from the pre-BZ-991149 days but doesn't really try to resolve the
essentially broken nature of our startup logic where we cannot really
guarantee the state of the container services (this is made worse by
the fact that the PluginContainer is a singleton to which any code
can get a reference in any stage of its lifecycle).