Bug 671476 - Fail to detect changes to existing, managed content
Summary: Fail to detect changes to existing, managed content
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Content
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: RHQ 4.4.0
Assignee: Stefan Negrea
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-21 15:55 UTC by John Sanda
Modified: 2014-09-02 15:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-02 15:45:02 UTC
Embargoed:


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

Description John Sanda 2011-01-21 15:55:48 UTC
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 17:00:47 UTC
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 19:09:28 UTC
Is this really a bug? Asking for an outside opinion...

Comment 3 Stefan Negrea 2014-09-02 15:45:02 UTC
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.