1 2 3 4 Previous Next 58 Replies Latest reply on Apr 10, 2013 6:16 AM by stuartdjames Go to original post
      • 45. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
        cpinon

        Hi,

        Thanks Ales for the quick reply...

        Obviously you're right! I was talking from replacing "COmbinedVFSCache" by LRU. I was confused by the "realCache" variable in the COmbined which is an IterableTimedCache.

        You're note on Permanent Cache lead me to do others tests and remind me something important that I forget to mention.

        We've defined an extra deploy dir in the "bootstrap/profile.xml"
        So if i deploy our application in the "deploy/" ==> Jars/Wars get cache in the "permanentCache" of the COmbined ==> Jars/wars are unzip once in the vfs-tmp!
        If i put the same ear in ou extra deploy dir ==> Jars/Wars get cache in the "realCache" of the Combined ==> they get unzip multiple times ....

        May be another (better ?) solution is to keep the Combined and use the LRU for the "realCache" ? - but didn't try yet. or find a way to cache the extra deploy dir in the permanent Cache.

        ------ * * * *

        A related point that - If i understand well - isn't normal in the VFS 2.1.2 GA and may affect performance ? (seems to be still true in 2.2)

        Let's start with the following method in the VFS class
        public static VirtualFile getRoot(URI rootURI) throws IOException
        --> call "VFSRegistry.getFile"
        ----> call "findContext" on the CombinedCache
        ----------> call realCache.findContext impl. by IterableTimedCache
        In this impl. if keys is found but is expired ==> Null will be returned and will be returned to VFS.getRoot
        In "VFS.getRoot", as "getFile" returned NULL we call :
        --> createNewRoot
        --> getVFS
        ----> DefaultVFSRegistry.addContext
        ------> Combined.putContext
        ---------> CachePolicyVFSCache.putContext (Inherited by IterabletimedCache)

        Here, we do a "peek" and and if the key is returned we put it in the Cache.
        But as we do a "peek" we don't check if the key is expired !?
        ==> So it seems to me, that once the value is present we don't(never?) refresh it ? because the "peek" call. Do I miss something ?

        Hope i've been clear in my explanation.

        CP


        • 46. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
          alesj

           

          "cpinon" wrote:

          May be another (better ?) solution is to keep the Combined and use the LRU for the "realCache" ? - but didn't try yet. or find a way to cache the extra deploy dir in the permanent Cache.

          What you must do in this case it to have your new deploy dir in-synch with permanent roots in boostrap/vfs.xml.
          e.g. add the same URL/path to the vfs.xml as you did in profile.xml

          Unfortunately I currently don't see any nice way to have these to automatically synched.

          "cpinon" wrote:

          A related point that - If i understand well - isn't normal in the VFS 2.1.2 GA and may affect performance ? (seems to be still true in 2.2)

          Let's start with the following method in the VFS class
          public static VirtualFile getRoot(URI rootURI) throws IOException
          --> call "VFSRegistry.getFile"
          ----> call "findContext" on the CombinedCache
          ----------> call realCache.findContext impl. by IterableTimedCache
          In this impl. if keys is found but is expired ==> Null will be returned and will be returned to VFS.getRoot
          In "VFS.getRoot", as "getFile" returned NULL we call :
          --> createNewRoot
          --> getVFS
          ----> DefaultVFSRegistry.addContext
          ------> Combined.putContext
          ---------> CachePolicyVFSCache.putContext (Inherited by IterabletimedCache)

          Here, we do a "peek" and and if the key is returned we put it in the Cache.
          But as we do a "peek" we don't check if the key is expired !?
          ==> So it seems to me, that once the value is present we don't(never?) refresh it ? because the "peek" call. Do I miss something ?

          I think in this case we're already doing get before peek.
          And this get should invalidate that properly.

          And even though we might miss some get before peek,
          I think it wouldn't matter much, as this is not really highly detailed/precise cache.
          The limitations are mostly there in order not to grow over proportions.

          • 47. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
            michaelfgh

            I am having the same issue, I use the JBoss 5.0.0,
            about this, I am a fresh, my OS is Linux (RH4.7) and Windows XP,
            through reading all the message, it seemed to chang 5.0.1 that is the best solution,
            I want to know if I use the new version, I whether should chose 5.1.0,
            if I still use the 5.0.0, how to do?
            only modify the vfs.xml according the new version, is it feasible?
            any help will be appreciated,
            please!

            • 48. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
              alesj

               

              "michaelfgh" wrote:

              through reading all the message, it seemed to chang 5.0.1 that is the best solution,
              I want to know if I use the new version, I whether should chose 5.1.0,
              if I still use the 5.0.0, how to do?

              I would update to 5.1.0.GA.

              • 49. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                michaelfgh

                Hi, Ales, thanks for you advice very much,
                regarding the vfs.xml

                <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>
                 </map>
                 </property>
                


                now I have a doubtful point, these url whether need to be replace by the real path, if YES, what is its function?
                if NO, is it wrong?
                Thanks again.



                • 50. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                  jaikiran

                  Those ( ${jboss.lib.url} ) and other such properties being used in that file will be replaced dynamically by JBoss. There are several such properties available. See this for more details http://www.jboss.org/community/wiki/JBossProperties

                  these url whether need to be replace by the real path


                  So, no you don't have to replace those with real path.


                  • 51. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                    michaelfgh

                    Thanks for Jaikiran's reply,
                    Now the JBoss 5.1.0 is in my use, I can see the jar files does not inflate infinitely, but I find under the /tmp directory, many other folders are created, there are some *.war files in some folders and more folders is empty. The number of these folder increase with the time, but the /tmp size is not enlarged. As this status, is it correct?
                    Is it harmless? Do I need to mind it?
                    Thanks a million.

                    • 52. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                      alesj

                       

                      "michaelfgh" wrote:

                      Now the JBoss 5.1.0 is in my use, I can see the jar files does not inflate infinitely, but I find under the /tmp directory, many other folders are created, there are some *.war files in some folders and more folders is empty. The number of these folder increase with the time, but the /tmp size is not enlarged. As this status, is it correct?

                      Those are guid named directories, since we need to diff between different libs with the same name while unpacking them from diff apps.

                      e.g. foo.ear/lib/log4j.jar and bar.ear/lib/log4j.jar
                      where foo's log4j is version 1.2 and bar's is 1.1, hence it might not be compatible

                      Not to mention different apps can have custom jars named the same way but are completely different.
                      e.g. my apps JPA entities ales.ear/lib/entities.jar vs. mike.ear/lib/entities.jar

                      "michaelfgh" wrote:

                      Is it harmless? Do I need to mind it?

                      They will be deleted once you restart your app server.

                      • 53. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA

                         

                        "alesj" wrote:

                        "michaelfgh" wrote:

                        Is it harmless? Do I need to mind it?

                        They will be deleted once you restart your app server.


                        But for a long-running production server, this is still a problem, correct? On one server I've got folders from July 29th with the UID names like "2q4u2720-n4u4eu-fxq9wcza-1-fxq9xa01-dl".

                        • 54. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                          alesj

                           

                          "otherdave" wrote:
                          "alesj" wrote:

                          "michaelfgh" wrote:

                          Is it harmless? Do I need to mind it?

                          They will be deleted once you restart your app server.


                          But for a long-running production server, this is still a problem, correct?

                          I don't think it should be a huge problem. As they don't occupy a lot of space.
                          And unless you're re-deploying like mad, you won't have a lot of them present.
                          (depending on # of nested jars)

                          • 55. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                            brettcave

                            I came across this problem on 5.1.0.GA with hdscanner disabled (the -jboss-beans.xml file removed from deploy). I was installing artifactory to JBoss and stuck it in the deploy directory. On startup, the tmp directory is about 30mb, with all the jars from the webapp in it. When i start using the webapp, the tmp/vfs-nested.tmp directory jumps to double the size, with all the jars from the war being redeployed. As I use the webapp, it gets to a point where the jars start duplicating, and within 20 minutes, i have over 70 copies of each jar, with a tmp directory size of 3gb (its on a VM with a small drive, so at this point, i run out of disk space).

                             

                            I resolved the issue by add 2 parameters to the JBoss environment:

                            JBOSS_OPTS="$JBOSS_OPTS -Djboss.vfs.forceNoCopy=true -Djboss.vfs.forceCopy=false"

                             

                            this disabled the vfs-nested.tmp directory from being used (which I thought was default for 5.1.0.GA ... ?)

                             

                            My next question though is - surely in-memory redeployment of these would result in memory usage increase and eventually heap space / permgen memory issues, as apposed to disk usage? How else might performance be affected by changing to this configuration? I have just come across this issue now, and would like to start investigating it for production use.....

                            • 56. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                              stuartdjames

                              I had the same issue described above in production and resolved it with the following solution.

                               

                              Added java options

                              -Djboss.vfs.cache=org.jboss.virtual.plugins.cache.IterableTimedVFSCache\

                              -Djboss.vfs.cache.TimedPolicyCaching.lifetime=1440\

                               

                              My setup also defines additional deployment directories so I needed to add these additional directories to vfs.xml file located in $JBOSS_SERVER_HOME/conf/bootstrap/ in order to see the benefit.

                               

                              The lifetime setting I think is in minutes so I set it to a day as I have a scheduled restart of the server overnight. 

                               

                              Prior to finding this solution I had also tried using

                              -Djboss.vfs.forceNoCopy=true  and

                              -Djboss.vfs.forceCopy=false

                              This appeared to work but I also noticed the application ran a lot slower - presumably because these settings turn vfs caching off.

                               

                              My Jboss version is jboss-5.1.0.GA and my application runs in a cluster on production.

                              • 57. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                                nikosys

                                Hi Stuart,

                                I am facing same issue on my production system.There are hundreds of pdf file in jboss server cache.I think your solution should work

                                for my problem.But,in which  file i have to add above java options? My question is silly but i am new to jboss 5.

                                Thanks.

                                • 58. Re: -Djboss.vfs.forceNoCopy=true not working AS 5.0.0.GA
                                  stuartdjames

                                  Hi Niks,

                                   

                                  You need to add these parameters to your Jboss startup script. The startup script in a default install is located in $JBOSS_HOME/bin and depending on the OS is either run.bat or run.sh.  Towards the end of the file you'll find a series of echo lines followed by the start/restart  java command.  Add it there.

                                   

                                  Cheers,

                                   

                                  Stuart

                                  1 2 3 4 Previous Next