[jboss-jira] [JBoss JIRA] (JBVFS-166) Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'

[Chris Sams (JIRA)]

    [ https://issues.jboss.org/browse/JBVFS-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12690866#comment-12690866 ] 

Chris Sams commented on JBVFS-166:
----------------------------------

@Ales

The permanent root should be a symlink and then something within it also should be a symlink whose resolved location does not include the permanent root's resolved path.

For example:
/vfs/symlink/im_a_symlink_too.jar

/vfs/symlink can be the root and resolve to /tmp

im_a_symlink_too.jar can resolve to /othertmp/the_real_jar.jar

/tmp always goes in the permanent cache regardless of whether forceCanonical is true (from the property editor canonicalizing the path).

If forceCanonical is true, subsequent accesses of /vfs/symlink/im_a_symlink_too.jar resolve to /othertmp/the_real_jar.jar, which isn't found in either the permanent or real cache.  When adding the path to the cache after the miss, the uncanonicalized version is used, so a cache miss occurs every time after that, too.

Now suppose forceCanonical is false.  Then the path /vfs/symlink/im_a_symlink_too.jar is used when accessing a resource, and it gets added to the IterableTimedCache, which times out every 30 minutes.  If the contents of the archive are exploded in memory, then you might not notice unless you update the jar and then wait for the timeout.

There's an additional complexity when the archive is a deployed WAR file because the AbstractWarDeployer does the following on deployment:

VFSDeploymentUnit vfsUnit = (VFSDeploymentUnit)unit;
VirtualFile root = vfsUnit.getRoot();
VirtualFile unjared = VFSUtils.unjar(root);

This is a problem because the TempInfo for the WAR is attached to the FileSystemContext of the deployment directory, which is always missed when accessing resources in the WAR.  Instead those resources are loaded either directly from the WAR (every time if forceCanonical is true) or from memory (which gets refreshed every 30 minutes because of the IterableTimedCache timeout).  Regardless, they're not coming from tmp as they should.

I think that fixing the symlink resolution problems will fix the problem with the WAR also because all of the paths used should be consistent.


                
> Deployment archives that are symlinks do not get cached properly when jboss.vfs.forceCanonical is set to 'true'
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: JBVFS-166
>                 URL: https://issues.jboss.org/browse/JBVFS-166
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  2.2.0.GA
>            Reporter: Mike Clark
>            Assignee: Ales Justin
>
> When a deployment, such as an .ear file, is a symlink and the jboss.vfs.forceCanonical property is set to "true" to address JBVFS-137, the deployment fails to be properly cached leading to an ever increasing vfs-nested.tmp directory.
> JBVFS-137 addresses the problem that permanentRoots in the VFSCache get set according to their canonical path by the URL PropertyEditor.  Without the fix, if the deployment directory is a symlink, it will be stored in the cache using a different path than lookups will use.  To correct this, when checking for items in the cache, the canonical path must be used, or else there will not be a match.  Setting the jboss.vfs.forceCanonical property enables conversion of the deployment's path to a canonical path for this purpose.
> However, in the case of a deployment that is a symbolic link within the deploy directory (i.e., someApp.ear is itself a symbolic link), there is no initial modification of the path to a canonical path. (Because the URL is not being set via a PropertyEditor.)  So, it is stored based on the non-canonical path.  But, with jboss.vfs.forceCanonical set to true, the lookup is based on the canonical path, which doesn't match.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira