Bug 702691 - ProcessInfo in resource context never refreshes
Summary: ProcessInfo in resource context never refreshes
Alias: None
Product: RHQ Project
Classification: Other
Component: Agent
Version: 4.0.1
Hardware: Unspecified
OS: Unspecified
high vote
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
Depends On:
Blocks: jon3 694476
TreeView+ depends on / blocked
Reported: 2011-05-06 15:33 UTC by Lukas Krejci
Modified: 2013-09-02 07:25 UTC (History)
3 users (show)

Clone Of: 700461
Last Closed: 2013-09-02 07:25:25 UTC

Attachments (Terms of Use)

Description Lukas Krejci 2011-05-06 15:33:28 UTC
+++ This bug was initially created as a clone of Bug #700461 +++

Description of problem:

the ResourceContext instance the plugins can use to get info about, well, the context the resource component is running in contains the getNativeProcess() method which should contain the information about the current native process of the native resource.

This process information should be refreshed whenever the process is found not running, i.e. we should transparently handle process restarts.

If the process of the resource is restarted outside of agent control, the process info never refreshes and the component therefore has stale info.

Version-Release number of selected component (if applicable):
RHQ 3.0.1

How reproducible:

Steps to Reproduce:
1. discover and inventory an apache instance
2. Check the pid reported by the resourceContext.getNativeProcess().getPid()
3. restart apache from commandline, while the agent is running
4. repeat 2.
Actual results:
The pid reported in 2. and 4. is the same

Expected results:
4. should report the pid of the new apache process

Additional info:

This is not explicitly testable in any other way than by actually debugging the code, so QA will not be able to test this.

--- Additional comment from mazz@redhat.com on 2011-04-28 10:52:27 EDT ---

this has been an issue for at least 3 years :) From our initial git commit back in Feb 2008, you'll see this:

    public ProcessInfo getNativeProcess() {
        if ((this.processInfo == null) || !this.processInfo.isRunning()) {
            // TODO: should we null out processInfo?  if it isn't running, the old processInfo is no longer valid

The TODO shows that we knew this might be an issue. I remember talking about this issue a long time ago - not sure if we did anything about it (apparently, we didn't).

But, this would be the area that we'd have to touch to correct this (ResourceContext.java)

--- Additional comment from lkrejci@redhat.com on 2011-04-28 14:21:36 EDT ---

Well, the actual issue is that "this.processInfo.isRunning()" returns true even if the process no longer exists...

We need a call to processInfo.refresh() in the ResourceContext.getNativeProcess() to refresh that info.

Comment 1 Lukas Krejci 2011-05-16 11:21:28 UTC
commit 508fae8bb1cb9a3d161754a753a36b7781315ccd
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Fri May 6 17:35:20 2011 +0200

    BZ 702691 - ResourceContext.getNativeProcess() now always reports the current process info or null if no process exists for given resource.

Comment 2 Heiko W. Rupp 2011-05-16 11:37:34 UTC
We should go over all plugins to see if they dereference the process info without a check for null. The samba one did for example not have the check and thus throw NPEs over the place.

Comment 3 Lukas Krejci 2011-05-16 12:37:23 UTC
Commit in release-4.0.0 branch:


Comment 4 Lukas Krejci 2011-05-16 16:51:26 UTC
Steps to test:

1) In an apache configuration define 2 vhosts, one "plain", one nested inside an IfDefine:

Listen 8080
Listen 8081




2) start apache server:

apachectl start

3) discover the server in RHQ, only the vhost should appear.

4) restart the apache server

apachectl stop
apachectl -k start -D RHQ_TESTING

5) on agent commandline do "discovery -f"

6) the second vhost should be discovered

Comment 5 Sunil Kondkar 2011-05-17 12:31:08 UTC
Verified on build#31 (Version: 4.0.1-SNAPSHOT Build Number: dc9a4b6)

Defined 2 vhosts, one "plain" and one nested inside the IfDefine as explained in the steps.

Discovered the server in RHQ, the vhost appeared. After restarting with RHQ_TESTING parameter and doing discovery -f at agent prompt, the second vhost is discovered.

Marking as verified.

Comment 6 Heiko W. Rupp 2013-09-02 07:25:25 UTC
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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