Red Hat Bugzilla – Bug 671476
Fail to detect changes to existing, managed content
Last modified: 2014-09-02 11:45:02 EDT
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):
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.
Nothing is added to the package history for the WAR file even though it has been changed.
There should be an entry in the WAR file's package history indicating that it has changed.
This bug is not specific to RHQ 4.0. It is present in RHQ 3.0 and maybe even in earlier versions as well.
I want to point out that this bug is not specific to EARs and WARs. This issue effects all content backed resources.
Is this really a bug? Asking for an outside opinion...
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.