This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 820704 - when the Agent is running before the Server is started, and then the Server is started, the Agent's inventory can become out of sync with the Server's inventory for up to 15 mins (until the next scheduled discovery scan is run)
when the Agent is running before the Server is started, and then the Server i...
Status: NEW
Product: RHQ Project
Classification: Other
Component: Agent, Plugin Container (Show other bugs)
4.4
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-10 13:57 EDT by Ian Springer
Modified: 2015-02-01 18:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2012-05-10 13:57:33 EDT
This is because once the Agent's Server polling thread detects the Server has come up, it (or some other agent class that is a listener of the server polling thread) should either:

1) tell the PC it needs to restart

or:

2) tell the PC to do an inventory sync, i.e. call inventoryManager.handleReport(new InventoryReport(inventoryManager.getAgent()))
Comment 1 Ian Springer 2012-05-10 14:04:19 EDT
Otherwise, if the PC is out-of-sync, it will not sync itself up until the next scheduled discovery scan is run (since after every discovery scan, the PC performs a sync). This can take up to 15 minutes (the default server scan interval).

---

(01:35:46 PM) jshaughn: ips, if we make a change like that I'd recommend a full PC restart so we don't cut any corners
(01:36:39 PM) jshaughn: it only happens when a server comes up, not very frequent at all
(01:36:55 PM) ips: jshaughn: here's the stack for the server side exception: http://pastebin.com/qXnL6iFE
(01:38:03 PM) ips: jshaughn: perhaps, though that could cause a bunch of NPE's in the agent log, unless my new graceful shutdown flag is enabled in the PC config  :}
(01:38:35 PM) ips: and graceful shutdown can take anywhere from 15 to 90 seconds
(01:39:19 PM) ips: besides no NPE's, just doing the sync will be quicker and take care of the issue at hand
(01:39:32 PM) jshaughn: well, then the sync needs to complete before messages are sent, or we get the same problem
(01:40:49 PM) jshaughn: although even an avail report should be unlikely, once reported avail changes are few and far between in prod scenarios
(01:41:29 PM) ips: well sync only takes a couple seconds typically
(01:42:21 PM) ips: well, let me create 2 bz's - one for the agent side issue and one for the avail insert issue
(01:43:16 PM) mazz: all I know is - getting the agent startup (with the fact that we have the comm layer, an independent PC that knows nothing about the comm or even a server) and this fact we need to register and CONNECT as the very first thing) is hard to get right.
(01:43:44 PM) mazz: what I'm trying to say is, this wn't be trivial to understand all the ramifications of any changes here
(01:44:42 PM) jshaughn: mazz, I agree. I hate making changes in this area.  And given that, I change my mind to just perform a sync if we do anything at all.

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