Bug 671476 - Fail to detect changes to existing, managed content
Fail to detect changes to existing, managed content
Product: RHQ Project
Classification: Other
Component: Content (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: GA
: RHQ 4.4.0
Assigned To: Stefan Negrea
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2011-01-21 10:55 EST by John Sanda
Modified: 2014-09-02 11:45 EDT (History)
2 users (show)

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

Attachments (Terms of Use)
simple war file for testing (842 bytes, application/octet-stream)
2011-01-21 10:55 EST, John Sanda
no flags Details

  None (edit)
Description John Sanda 2011-01-21 10:55:48 EST
Created attachment 474636 [details]
simple war file for testing

Description of problem:
The agent runs content discovery at regularly scheduled intervals which I believe is every 30 seconds by default. For content that has been previously discovered but has changed in some way, we fail to detect the change(s). An example of this is with a WAR file that you manually deploy to a managed EAP instance. The WAR file will be discovered after it is deployed. Now suppose you deploy a modified version of the WAR file. The content discovery fails to detect that the WAR file has changed.

During content discovery the plugin container calls the discoverDeployedPackages method of each plugin that implements the ContentFacet API. That method returns a set of ResourcePackageDetails objects. The plugin container compares those returned ResourcePackageDetails against the current, known ResourcePackageDetails for managed content. That comparison comes down to the equals() and hashCode() method of ResourcePackageDetails. I beleive the implementation of these methods is in error. ResourcePackageDetails.equals and ResourcePackageDetails.hashCode compare and use the package (i.e., file) name, the package version, the package type name, and the architecture. They do not use the SHA-256 sum that is part of the ResourcePackageDetails.

If ResourcePackageDetails.equals and ResourcePackageDetails.hashCode are refactored to include the SHA-256 sum in their logic, we would detect changes to deployed content.

To make things clearer, suppose I initially deploy a WAR file that contains one JSP file. Then I later deploy the WAR file with two or three JSP files in it. The second WAR file is obviously different, as in a different version of the original.

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

How reproducible:

Steps to Reproduce:
1. Get an EAP 5 instance into inventory
2. Copy a WAR file to <jboss_home>/server/default/deploy
2.1 You can use the test.war that I will attach to the BZ
3. Check the inventory browser in the UI that you see test.war or whatever WAR you have deployed
4. Now make a change to test.war. This can be as simple as modifying the index.jsp that is included. It just contains plain text. Or you add another file to the WAR which could be a copy of index.jsp.
5. Wait 10 to 15 minutes for content discovery to run. 
Actual results:
Nothing is added to the package history for the WAR file even though it has been changed.

Expected results:
There should be an entry in the WAR file's package history indicating that it has changed.

Additional info:
This bug is not specific to RHQ 4.0. It is present in RHQ 3.0 and maybe even in earlier versions as well.
Comment 1 John Sanda 2011-01-21 12:00:47 EST
I want to point out that this bug is not specific to EARs and WARs. This issue effects all content backed resources.
Comment 2 Jay Shaughnessy 2014-07-03 15:09:28 EDT
Is this really a bug? Asking for an outside opinion...
Comment 3 Stefan Negrea 2014-09-02 11:45:02 EDT
This has been fixed a long time ago when the content system was overhauled. At the time both AS4 and AS5 plugins were completely corrected. 

Content version is now the hash of all files, so when something changes on disk the content discovery reports that a new version was discovered. There are still some edge cases with a delay in reporting exploded content changes, but in most cases the changes are detected fast.

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