8 Replies Latest reply on Nov 4, 2008 9:30 AM by alesj

    VFS and JBossAS initialization

    alesj

      In order to speed/cache things up, I suggest the following addition:
      bootstrap.xml

      <bootstrap xmlns="urn:jboss:bootstrap:1.0">
      
       <url>initialize.xml</url>
       <url>classloader.xml</url>
      

      Where initialize.xml would look like:
      <!--
       The JBossAS initializer configuration.
      -->
      <deployment xmlns="urn:jboss:bean-deployer:2.0">
      
       <bean name="VFSCache">
       <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance"/>
       <uninstall method="stop"/>
       </bean>
      
       <bean name="JBossVFSInitializer" class="org.jboss.virtual.plugins.cache.PreInitializeVFSContexts">
       <property name="initializedVFSContexts">
       <list elementClass="java.net.URL">
       <value>${jboss.lib.url}</value>
       <value>${jboss.server.lib.url}</value>
       </list>
       </property>
       </bean>
      
       <bean name="SingletonSchemaResolverFactory" class="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory">
       <constructor factoryClass="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory" factoryMethod="getInstance"/>
       <install method="addJaxbSchema">
       <parameter>urn:jboss:caching-classloader:1.0</parameter>
       <parameter>org.jboss.classloading.spi.vfs.metadata.CachingVFSClassLoaderFactory10</parameter>
       </install>
       </bean>
      
      </deployment>
      


      The first bean just says we should stop cache after we're done.
      The 2nd one pre-initializes some of the most commonly used vfs roots,
      hence pushing matching contexts into vfs cache.
      The last is VFSClassLoaderFactory metadata that works off the vfs cache.

      I'm already running this, which results in this minimal cache:
      - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186390#4186390

      What do you think?

        • 1. Re: VFS and JBossAS initialization

           

          "alesj" wrote:
          In order to speed/cache things up, I suggest the following addition:
          bootstrap.xml
          <bootstrap xmlns="urn:jboss:bootstrap:1.0">
          
           <url>initialize.xml</url>
           <url>classloader.xml</url>
          

          Where initialize.xml would look like:
          <!--
           The JBossAS initializer configuration.
          -->
          <deployment xmlns="urn:jboss:bean-deployer:2.0">
          
           <bean name="VFSCache">
           <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance"/>
           <uninstall method="stop"/>
           </bean>
          
           <bean name="JBossVFSInitializer" class="org.jboss.virtual.plugins.cache.PreInitializeVFSContexts">
           <property name="initializedVFSContexts">
           <list elementClass="java.net.URL">
           <value>${jboss.lib.url}</value>
           <value>${jboss.server.lib.url}</value>
           </list>
           </property>
           </bean>
          
           <bean name="SingletonSchemaResolverFactory" class="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory">
           <constructor factoryClass="org.jboss.xb.binding.sunday.unmarshalling.SingletonSchemaResolverFactory" factoryMethod="getInstance"/>
           <install method="addJaxbSchema">
           <parameter>urn:jboss:caching-classloader:1.0</parameter>
           <parameter>org.jboss.classloading.spi.vfs.metadata.CachingVFSClassLoaderFactory10</parameter>
           </install>
           </bean>
          
          </deployment>
          


          The first bean just says we should stop cache after we're done.
          The 2nd one pre-initializes some of the most commonly used vfs roots,
          hence pushing matching contexts into vfs cache.
          The last is VFSClassLoaderFactory metadata that works off the vfs cache.


          Why CachingVFSClassLoaderPolicy?

          Remember our isA/hasA discussion?

          Is a vfs classloader policy a vfs cache or can a vfs classloader policy
          have a vfs cache?

          If like me you think it is the latter then it is not a subclass it is a property
          (although you might conceivable temporarily subclass to experiment with
          adding the property).

          The scalability problem of maintaining and supporting a whole new schema should be
          a warning sign. Are you going to create a new schema for every new feature?


          I'm already running this, which results in this minimal cache:
          - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4186390#4186390

          What do you think?


          • 2. Re: VFS and JBossAS initialization

            Also, I think you're trying to solve the problem at the wrong level.

            As we discussed before when I put the original VFS file caching in the
            VFSClassLoaderPolicy, this was just a temporary workaround because
            the VFS didn't have such behaviour itself.

            • 3. Re: VFS and JBossAS initialization
              alesj

               

              "adrian@jboss.org" wrote:

              Is a vfs classloader policy a vfs cache or can a vfs classloader policy
              have a vfs cache?

              I didn't want to change current impl at the following code:
               /**
               * Get virtual file for uri.
               *
               * @param uri the uri
               * @return virtual file for uri
               * @throws Exception for any error
               */
               protected VirtualFile getVirtualFile(URI uri) throws Exception
               {
               return VFS.getRoot(uri);
               }
              

              instead doing an override that uses the newly added caching VirtualFile instance re-usability:
               protected VirtualFile getVirtualFile(URI uri) throws Exception
               {
               return VFS.getCachedFile(uri);
               }
              


              Perhaps I can use VFS::getCachedFile directly in the original impl?
              Hence no need for the additional class.

              VFS::getCachedFile:
               /**
               * Get cached file.
               *
               * If VFSContext matching the rootURL parameter is cached
               * this method will return cached virtual file
               * else it will use VFS::getRoot(rootURL).
               *
               * @param rootURL the root url
               * @return the cached virtual file
               * @throws IOException for any error
               * @throws IllegalArgumentException if the rootURL is null
               */
               public static VirtualFile getCachedFile(URL rootURL) throws IOException
               {
               VFSCache cache = VFSCacheFactory.getInstance();
               return cache.getFile(rootURL);
               }
              


              • 4. Re: VFS and JBossAS initialization

                Why isn't this just based on the isCachable() attribute?

                • 5. Re: VFS and JBossAS initialization
                  alesj

                   

                  "adrian@jboss.org" wrote:
                  Why isn't this just based on the isCachable() attribute?

                  Dunno. Probably just some temp hype with super classing everything. :-)
                  I'll add this, making it true by default.

                  I think this kind of URI --> VirtualFile code should mostly use this newly added VFS::getCachedFile method.
                  Unless you're really sure you need to create new VFSContext (that's what VFS::getRoot does)
                  or you're absolutely sure this resource is not cached, hence introducing performance impact, you should use the old way.

                  • 6. Re: VFS and JBossAS initialization

                    It already exists it comes from the ClassLoadingMetaData

                    It specifies whether you are allowed to cache resource hits, i.e. whether resources
                    could disappear at random.

                    I agree its probably not relevant for the roots of the vfs classloader
                    since they have to exist (see determineVFSRoots):

                    • 7. Re: VFS and JBossAS initialization
                      alesj

                       

                      "adrian@jboss.org" wrote:
                      I agree its probably not relevant for the roots of the vfs classloader
                      since they have to exist (see determineVFSRoots):

                      Yeah, it's not really related, but I guess we can re-use it.

                      • 8. Re: VFS and JBossAS initialization
                        alesj

                         

                        "alesj" wrote:

                        Yeah, it's not really related, but I guess we can re-use it.

                         protected VirtualFile getVirtualFile(URI uri) throws Exception
                         {
                         if (isCacheable())
                         return VFS.getCachedFile(uri);
                         else
                         return VFS.getRoot(uri);
                         }