[jboss-dev] Problem detecting modified deployments

[Ales Justin]

You only need StructCache if the actual
VirtualFile instance changes.
Roots in Deployment(Context) don't change.

Sent from my iPhone

On Apr 21, 2009, at 19:18, Brian Stansberry  
<brian.stansberry at redhat.com> wrote:

> This would be a "Design of POJO Server" thread but forums are down  
> so am using this broad distribution list. Those not interested in  
> the technical details of detecting modified deployments can  
> ignore.  :)
>
> I'm looking for some input from the VFS and ProfileService folks.
>
> I'm having an issue where the ClusteredDeploymentRepository is  
> failing to detect modified deployments. Issue leads to a failure in  
> a newly added test[1].  What the test does is make some changes in  
> the contents of the farm/ dir, gives time for the HDScanner to run,  
> and then verifies that the updated content is deployed in all nodes  
> in the cluster. Everything works fine for content additions and  
> removals, but modifying an existing file doesn't work.
>
> Problem is in the  
> ClusteredDeploymentRepository.createModificationInfo() method, which  
> basically duplicates the logic in  
> HotDeploymentRepository.getModifiedDeployments(). Loops through the  
> VirtualFiles representing the root of known deployments, checking if  
> they are removed, and if not, asking the  
> StructureModificationChecker if  they are modified:
>
> // Check for modification
> else if (hasDeploymentContentFlags(pathName,  
> DeploymentContentFlags.MODIFIED)
>      || getChecker().hasStructureBeenModified(root))
> {
>   long rootLastModified = root.getLastModified();
>   ...
>   // Create the modification info
>   ModificationInfo info = new ModificationInfo(ctx,  
> rootLastModified, ModifyStatus.MODIFIED);
>   modified.add(info);
> }
>
> Problem occurs in  
> AbstractStructureModificationChecker.hasStructureBeenModified 
> (VirtualFile):
>
>   if (root == null)
>      throw new IllegalArgumentException("Null root");
>
>   // skip vfs deployment context lookup if archive or file
>   if (root.isArchive() || root.isLeaf())
>      return root.hasBeenModified();  // !!! RETURNS FALSE
>
> The problem is root.hasBeenModified() returns false. I don't think  
> VirtualFile.hasBeenModified() is a safe way to check for  
> modification, since following a modification, it will return true  
> once and only once. So whatever code asks first gets "true", later  
> code will get "false". AFAICT, this is the reason  
> AbstractStructureModificationChecker has a StructureCache injected  
> -- the cache stores modification timestamps to avoid this problem.
>
> Shouldn't the timestamps for archives/leaf deployments be stored in  
> the StructureCache as well? And then check for modification using  
> the StructureCache's data, same as we do for, e.g. a WEB-INF/web.xml?
>
> FYI, the reason that in this case root.hasBeenModified() returns  
> false is earlier in the HDScanner run ClusteredDeploymentRepository  
> has scanned the repository content looking for changes so it can  
> replicate modified files around the cluster. That scan results in a  
> call to VirtualFile.getChildren() which ends up calling  
> AbstractVirtualFileHandler()hasBeenModified().
>
> A final twist:
>
> While experimenting with this manually, I found that the first time  
> I modify the file, the above problem occurs. But then if I modify  
> the file  again, it gets picked up as modified and redeployed. And  
> thereafter, every time I modify it, it gets redeployed.  Only fails  
> the first time. I've been poking around a long time and have no  
> explanation for why this is.
>
> [1] http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-testSuite-sun15/219/testReport/org.jboss.test.cluster.defaultcfg.profileservice.test/FarmedClusterHotDeployUnitTestCase(ClusteredProfileService)/testFarmHotDeployment/
>
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> brian.stansberry at redhat.com
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development