+++ This bug was initially created as a clone of Bug #772771 +++

This needs to be validated further but it seems that the agent may
not be picking up updated plugin config at startup.

0) Import RHQ Server resource
1) Shut down agent
2) Enable the built in log event source (and optionally make other changes
   to it)
3) Save new config

This will generate a config update failure because the live config
could not be updated.  But the config is updated in the db and the
config history shows the change, with the agent update error. This,
although maybe not totally intuitive, is expected.

4) Start the agent 

You can do this in debug if you like, and set a break in
public void startLogFileEventPollers().  At the break you should see
that the logEventSource is still disabled and no other changes are
reflected.

No log message events will be generated.

There may be easier ways to repro this, perhaps just changing the 
JNP url and if the resource still connects you know it's not using
the updated value.

--------

Additionally, given the break point set above, I noticed the component
start() method getting called more than once (without intervening stop()
calls.  This is something to also look into, and will merit another BZ if
it is in fact happening.

--- Additional comment from jshaughn on 2012-01-10 12:45:59 EST ---

master commit 8eaf6da4148d2eeea265f5deb633ce7a295731ff

The resource mtime was not being properly updated when completing the
plugin config sync.  If the agent was down at update time it would not
know to sync the resource on startup, or at any point until perhaps
the resource was modified in some other way, or the plugin config was
changed when the agent was up.

Also, in general Resource.setAgentSynchronizationNeeded() should be called
by any code performing an update that requires agent sync. The
Resource.setMtime() method should not be called for this purpose, but
rather only when manual mtime manipulation is required.

Test Notes
You should be able to repro the failure scenario in either of the ways
described in the original comment.


p.s. The issue with multiple calls to a component start() has been moved
to a new bug 773031.