[skybeam]

It seems my previous analysis was not entirely correct.

I just noticed that I did not install jboss-vfs.jar in version 2.2.0.GA but instead I've installed version 2.2.0.M4 from the official Maven repository (http://repository.jboss.org/maven2/org/jboss/jboss-vfs/2.2.0.M4/). Then I found out that version 2.2.0.GA can be found at http://repository.jboss.org/maven2-brew/org/jboss/jboss-vfs/2.2.0.GA/ (I hope this is the correct location). Just wondering why it's not in the official maven2 location.

After installing this version and setting the default vfs.xml configuration and adding the -Djboss.vfs.forceCanonical=true startup parameter it seems to work fine. Even if I use the jboss.server.home.url property in vfs.xml.

Here's my vfs.xml property for reference:

{code}
<?xml version="1.0" encoding="UTF-8"?>
<!--
   The JBossVFS initializer configuration.
-->
<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="VFSCache">
    <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance">
      <!-- Use the CombinedVFSCache implementation -->
      <parameter>org.jboss.virtual.plugins.cache.CombinedVFSCache</parameter>
    </constructor>
    <start ignored="true"/>
    <property name="permanentRoots">
      <map keyClass="java.net.URL" valueClass="org.jboss.virtual.spi.ExceptionHandler">
        <entry>
          <key>${jboss.lib.url}</key>
          <value><null/></value>
        </entry>
        <entry>
          <key>${jboss.common.lib.url}</key>
          <value><inject bean="VfsNamesExceptionHandler"/></value>
        </entry>
        <entry>
          <key>${jboss.server.lib.url}</key>
          <value><inject bean="VfsNamesExceptionHandler"/></value>
        </entry>
        <entry>
          <key>${jboss.server.home.url}deploy</key>
          <value><inject bean="VfsNamesExceptionHandler"/></value>
        </entry>
        <entry>
          <key>${jboss.server.home.url}farm</key>
          <value><inject bean="VfsNamesExceptionHandler"/></value>
        </entry>
      </map>
    </property>
    <property name="realCache">
      <bean/>
    </property>
  </bean>

  <bean name="VfsNamesExceptionHandler">
    <constructor>
      <parameter>sqljdbc.jar</parameter>
    </constructor>
  </bean>

</deployment>
{code}

Reading this thread it looks to me that some people seem to be concerned about possible performance drop when using/enforcing canonical names. Is this likely to be a real issue or just a small impact?

Personally I think it will not be a big issue at runtime. Maybe a small impact during startup and deployment when canonical paths of the files need to be looked up. But after deployment there should not be much canonical path lookups required.

What do you think about? Or are there any benchmarks done with or without this option being enabled?

I am running JBoss 5.1.0 on Solaris 10 x86 (if this is relevant).

Thanks again for your help.

[alesj]

I just noticed that I did not install jboss-vfs.jar in version 2.2.0.GA but instead I've installed version 2.2.0.M4 from the official Maven repository (http://repository.jboss.org/maven2/org/jboss/jboss-vfs/2.2.0.M4/). Then I found out that version 2.2.0.GA can be found at http://repository.jboss.org/maven2-brew/org/jboss/jboss-vfs/2.2.0.GA/ (I hope this is the correct location). Just wondering why it's not in the official maven2 location.

This is the old JBoss mvn repo.

That version is in new Nexus repo:

* https://repository.jboss.org/nexus/index.html#view-repositories;public-jboss

Reading this thread it looks to me that some people seem to be concerned about possible performance drop when using/enforcing canonical names. Is this likely to be a real issue or just a small impact?

It's an additional step in path lookup, which you always have to do -- force the path to its canonical version.

Dunno how fast this op is in underlying OS.

Personally I think it will not be a big issue at runtime. Maybe a small impact during startup and deployment when canonical paths of the files need to be looked up. But after deployment there should not be much canonical path lookups required.

Exactly. ;-)

Or are there any benchmarks done with or without this option being enabled?

I would be great if you could post some stuff, as it seems you're on top of it. :-)

[skybeam]

{quote}
This is the old JBoss mvn repo.
That version is in new Nexus  repo:
* https://repository.jboss.org/nexus/index.html#view-repositories;public-jboss
{quote}

This is good to know. I am using Nexus as well. Great tool. I will make sure it's proxying the official nexus repository.

{quote}
I would be great if you could post some stuff, as it seems you're on top  of it. :-)
{quote}

Well, I am quite new to JBoss development. Actually I could do some tests but maybe you can drop me some hints how to perform a load test (any how-to?). Currently I am deploying an application which includes only 3 EAR files and a total size of 50MB with arount 100 jar files included. Running JBoss in "all" configuration takes about 2:30 to start up on this machine (SunFire 4170) and I even think I will not be able to measure any difference in startup time either with or without canonical paths enforced. So I would need some stresstest which shows some significant difference.

To be sure I will measure startup time with enforced and without enforcing canonical paths.

But if there is no typical scenario where canonical paths show significant slow-down I wonder why it's not enabled by default. Maybe it could be switched off on systems which do not have symlinks or where it's very uncommon to use symlinks (Windows?).

[mstruk]

I don't think we have any performance tests in VFS yet. I'm also not aware of any JBoss projects performance testing  how-to.

So here are a few things you want to have in mind specifically for testing symlink impact on performance.

First, you'll need to create a lot of symlinks, it's best they point to different files (to avoid filesystem caches) - so maybe create one directory with randomly named files and one directory with corresponding symlinks. Put a filename as content of each file.

Then use VFS on directory containing symlinks and visitor to iterate over them, read each virtual file - check that the content matches the name.

To compare the result, test nonsymlink access - delete the temp dirs and recreate just the files again using random names. Use VFS on directory containing files.

So ... the important thing is to try and neutralize the effect of filesystem caches, although in real life situations there will be a filesystem cache so does it really make sense to avoid it while testing? It depends on what you want to measure really.

The question is how realistic scenario the described test would be - having tons of symlinks. It's actually quite unrealistic as you typically don't go create symlinks for individual files, but for whole directories, so a test where the symlinks directory is actually a symlink to files directory is more realistic, but in this case again you benefit from filesystem caches.

I'd say - just cover all the scenarios