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.
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.
Remove the JON3.0.1 target release version, since we have BZ 785985 for that now.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.