Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 785985 - Agent not syncing updated plugin config at startup
Agent not syncing updated plugin config at startup
Product: RHQ Project
Classification: Other
Component: Agent (Show other bugs)
All All
urgent Severity high (vote)
: ---
: JON 3.0.1
Assigned To: Jay Shaughnessy
Mike Foley
Depends On: 772771
Blocks: jon30-sprint10/rhq43-sprint10 jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
Reported: 2012-01-30 23:41 EST by Charles Crouch
Modified: 2015-02-01 18:27 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 772771
Last Closed: 2013-09-03 11:11:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2012-01-30 23:41:16 EST
+++ 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

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@redhat.com 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.
Comment 3 Simeon Pinder 2012-02-02 14:35:33 EST
Moving to ON_QA as 3.0.1 RC2 is available from here:

Comment 4 Heiko W. Rupp 2013-09-03 11:11:06 EDT
Bulk closing of old issues in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.