Axis2
  1. Axis2
  2. AXIS2-3919

Temp folder being filled with files. Running out of disk space.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0, 1.1, 1.1.1, 1.2, 1.3, 1.4
    • Fix Version/s: 1.7.0
    • Component/s: kernel, modules
    • Labels:
      None
    • Environment:
      Windows XP, Linux

      Description

      Hi

      We are seeing an issue and it is holding us up from moving to production as our production servers would run out of disk space.

      This is in regards to a client that we are trying to implement using axis2-1.4 and rampart-1.3.

      We have a folder structure

      clientProjectFolder
      --otherFolders
      --....
      --....
      --axis2
      --conf
      --axis2.xml
      --modules
      --rampart1.3.mar

      our axis2.xml file contains the global module <module ref="rampart"/>
      In our client code, we make use of the fileSytemConfigurator to configure the client stub before making the call to our service.

      Every time we are calling the service, files are added to the TEMP folder (see below)

      C:\TEMP_axis2>dir
      Directory of C:\TEMP_axis2

      07/16/2008 08:36 AM <DIR> .
      07/16/2008 08:36 AM <DIR> ..
      07/16/2008 08:36 AM 2,704 axis2473rampart-1.3.mar
      1 File(s) 2,704 bytes
      2 Dir(s) 103,722,340,352 bytes free

      The same issue is being duplicated on our prod servers which are not windows based but linux based. the files get put in /tmp/_axis2 folder.

      Any advice on if there is a workaround for this?

      Thanks,
      Sujay

        Activity

        Sujay Chauhan created issue -
        Hide
        C. Brian Cox added a comment -

        This issue also plagues Solaris and AIX as well as version 1.4.1. For Solaris the files are placed in /var/tmp.

        Is anyone aware of a workaround for this issue, other then removal by cron? Also, can these files be configured to be placed into another directory?

        Thanks,

        Brian

        Show
        C. Brian Cox added a comment - This issue also plagues Solaris and AIX as well as version 1.4.1. For Solaris the files are placed in /var/tmp. Is anyone aware of a workaround for this issue, other then removal by cron? Also, can these files be configured to be placed into another directory? Thanks, Brian
        Hide
        Leandro Bonilla added a comment -

        To place files into another directory set System.setProperty("java.io.tmpdir","yours directory");

        The axis2 code that creates these files is

        public static File createTempFile(String suffix, InputStream in) throws IOException {
        byte data[] = new byte[2048];
        int count;
        new File(System.getProperty("java.io.tmpdir")).mkdirs();
        File f = File.createTempFile("axis2", suffix);
        f.deleteOnExit();
        FileOutputStream out = new FileOutputStream(f);
        while ((count = in.read(data, 0, 2048)) != -1)

        { out.write(data, 0, count); }

        out.close();
        return f;
        }

        on class org.apache.axis2.deployment.util.Utils.java

        Show
        Leandro Bonilla added a comment - To place files into another directory set System.setProperty("java.io.tmpdir","yours directory"); The axis2 code that creates these files is public static File createTempFile(String suffix, InputStream in) throws IOException { byte data[] = new byte [2048] ; int count; new File(System.getProperty("java.io.tmpdir")).mkdirs(); File f = File.createTempFile("axis2", suffix); f.deleteOnExit(); FileOutputStream out = new FileOutputStream(f); while ((count = in.read(data, 0, 2048)) != -1) { out.write(data, 0, count); } out.close(); return f; } on class org.apache.axis2.deployment.util.Utils.java
        Hide
        jacekw added a comment -

        The same issue observed on axis2 1.5, Tomcat 5.5 and Windows 2000.

        Any solution would be helpful.

        Thanks,
        Jacek

        Show
        jacekw added a comment - The same issue observed on axis2 1.5, Tomcat 5.5 and Windows 2000. Any solution would be helpful. Thanks, Jacek
        Hide
        Glen Daniels added a comment -

        We've replaced the referenced code with a TempFileManager class that does two things - 1) puts all files for a particular instance of Axis2 into a specific subdirectory of tmp_file_dir, and 2) ensures that old directories are cleaned up each time a new instance starts. This will solve the problem for the case where you're spinning up and down Axis2 instances... but not for a long running process (since the cleanup code is in a static block that gets initialized at JVM startup).

        The right long-term solution is to periodically clean up the temporary files when they are no longer needed - I think if we just store references to them in the appropriate context objects, we should be able to clean them up when the contexts are destroyed. I've targeted this for 1.6.

        Show
        Glen Daniels added a comment - We've replaced the referenced code with a TempFileManager class that does two things - 1) puts all files for a particular instance of Axis2 into a specific subdirectory of tmp_file_dir, and 2) ensures that old directories are cleaned up each time a new instance starts. This will solve the problem for the case where you're spinning up and down Axis2 instances... but not for a long running process (since the cleanup code is in a static block that gets initialized at JVM startup). The right long-term solution is to periodically clean up the temporary files when they are no longer needed - I think if we just store references to them in the appropriate context objects, we should be able to clean them up when the contexts are destroyed. I've targeted this for 1.6.
        Glen Daniels made changes -
        Field Original Value New Value
        Fix Version/s 1.6 [ 12313622 ]
        Hide
        Dirk Vanhalle added a comment -

        We too were filling up /var/tmp using an axis2 1.4 client application and this resulted in the system administrators removing our rights to write into that directory. Other than a warning in the logs, our client application did not encounter any problem.

        After some investigation, we found that the classloaders created for the modules first try to unpack the modules. Although org.apache.axis2.deployment.util.Utils.createClassLoader has a boolean parameter extractJars, the method is always called with this parameter set to true. We changed it to false in org.apache.axis2.deployment.DeploymentEngine and org.apache.axis2.deployment.repository.util.DeploymentFileData.

        There is 1 issue with this solution: Axis2 tries to deploy any services that might be included in the module (even if you use a module on the client side). It looks for the resource aars/aars.list in the module and all jars located in lib/ inside the module. This caused long load times of our own module, but removing the libs from the module solved this too.

        Show
        Dirk Vanhalle added a comment - We too were filling up /var/tmp using an axis2 1.4 client application and this resulted in the system administrators removing our rights to write into that directory. Other than a warning in the logs, our client application did not encounter any problem. After some investigation, we found that the classloaders created for the modules first try to unpack the modules. Although org.apache.axis2.deployment.util.Utils.createClassLoader has a boolean parameter extractJars, the method is always called with this parameter set to true. We changed it to false in org.apache.axis2.deployment.DeploymentEngine and org.apache.axis2.deployment.repository.util.DeploymentFileData. There is 1 issue with this solution: Axis2 tries to deploy any services that might be included in the module (even if you use a module on the client side). It looks for the resource aars/aars.list in the module and all jars located in lib/ inside the module. This caused long load times of our own module, but removing the libs from the module solved this too.
        Hide
        gerhard presser added a comment -

        I don't think that setting a system-property to specify the temp folder is a good way!

        i'm using axis2 in a tomcat environment. because axis2 is using the system property, my temp files are being created in the tomcat temp folder.
        so if multiple instances of my project are deployed in the same tomcat, all instances write to the same directory. but I want to controll where my temp files are created - per instance.

        It would be nice if I can set e.g. org.apache.axis2.deployment.util.TempFileManager.sTmpDir via some API!

        regards
        gerhard

        Show
        gerhard presser added a comment - I don't think that setting a system-property to specify the temp folder is a good way! i'm using axis2 in a tomcat environment. because axis2 is using the system property, my temp files are being created in the tomcat temp folder. so if multiple instances of my project are deployed in the same tomcat, all instances write to the same directory. but I want to controll where my temp files are created - per instance. It would be nice if I can set e.g. org.apache.axis2.deployment.util.TempFileManager.sTmpDir via some API! regards gerhard
        Hide
        Keith Roberts added a comment -

        I'm also running in to this issue. What I'm seeing is each time my app server deploys ears with axis2 in them, a temp directory and a temp lock file is created (for each one).

        I see in the code where it creates the lock file (in TempFileManager.java)
        // Create a lock before creating the directory so
        // there is no race condition with another application trying
        // to clean your temp dir.
        File lockFile = new File(tmpDirName, tmpDir.getName() + ".lck");
        lockFile.createNewFile();

        // Set the lock file to delete on exit so it is properly cleaned
        // by the JVM. This will allow the TempFileManager to clean
        // the overall temp directory next time.
        lockFile.deleteOnExit();

        And then in the static block
        // Create a file to represent the lock and test.
        File lockFile = new File(tmpFile.getParent(), tmpFile.getName() + ".lck");
        if (!lockFile.exists()) {
        // delete the temp directory

        However, the lock file is not getting deleted by the JVM, and so my temp directory fills with these directories over time each time the app server is restarted.

        From the javadocs:
        http://java.sun.com/javase/6/docs/api/java/io/File.html#createNewFile%28%29
        Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.

        Show
        Keith Roberts added a comment - I'm also running in to this issue. What I'm seeing is each time my app server deploys ears with axis2 in them, a temp directory and a temp lock file is created (for each one). I see in the code where it creates the lock file (in TempFileManager.java) // Create a lock before creating the directory so // there is no race condition with another application trying // to clean your temp dir. File lockFile = new File(tmpDirName, tmpDir.getName() + ".lck"); lockFile.createNewFile(); // Set the lock file to delete on exit so it is properly cleaned // by the JVM. This will allow the TempFileManager to clean // the overall temp directory next time. lockFile.deleteOnExit(); And then in the static block // Create a file to represent the lock and test. File lockFile = new File(tmpFile.getParent(), tmpFile.getName() + ".lck"); if (!lockFile.exists()) { // delete the temp directory However, the lock file is not getting deleted by the JVM, and so my temp directory fills with these directories over time each time the app server is restarted. From the javadocs: http://java.sun.com/javase/6/docs/api/java/io/File.html#createNewFile%28%29 Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.
        Hide
        Sasidhar BUDAMPATI added a comment -

        Hi,

        I am running into the similar issue. I am using tomcat 5.5.x on
        windows/linux.
        I find axisXXXXXXaxis2-1.4.jar files are created in
        tomcat_home/temp/_axis2/ is created and not getting purged. The problem
        persists only on production box. In development box the files are getting
        purged.

        Any suggestions/work around to fix this issue?

        Thanks,
        Sasidhar Budampati.
        *************************************************************************
        This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information.
        Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration.
        Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or
        falsified.
        ************
        Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes
        par le secret professionnel.
        Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite.
        Tout message electronique est susceptible d'alteration.
        La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie.
        *************************************************************************

        Show
        Sasidhar BUDAMPATI added a comment - Hi, I am running into the similar issue. I am using tomcat 5.5.x on windows/linux. I find axisXXXXXXaxis2-1.4.jar files are created in tomcat_home/temp/_axis2/ is created and not getting purged. The problem persists only on production box. In development box the files are getting purged. Any suggestions/work around to fix this issue? Thanks, Sasidhar Budampati. ************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. *************************************************************************
        Hide
        Amila Chinthaka Suriarachchi added a comment -

        please try with a nightly build[1]. This[2] may help you as well.

        [1]http://repository.apache.org/snapshots/org/apache/axis2/distribution/SNAPSHOT/
        [2]http://amilachinthaka.blogspot.com/2010/03/axis2-temp-files.html

        Show
        Amila Chinthaka Suriarachchi added a comment - please try with a nightly build [1] . This [2] may help you as well. [1] http://repository.apache.org/snapshots/org/apache/axis2/distribution/SNAPSHOT/ [2] http://amilachinthaka.blogspot.com/2010/03/axis2-temp-files.html
        Hide
        Markus Frick added a comment -

        Hello,
        we had the same problem with Version 1.4.1 on our Windows system.
        Every call of a client, that used AXIS2 resulted in a new file in the user-temp folder.
        In our case it was the mex-1.4.1.jar.

        As I examined the mex-1.4.1.jar, I found a "suspicious" file module.xml in the META-INF folder.

        When I removed it, the problem was solved.

        Show
        Markus Frick added a comment - Hello, we had the same problem with Version 1.4.1 on our Windows system. Every call of a client, that used AXIS2 resulted in a new file in the user-temp folder. In our case it was the mex-1.4.1.jar. As I examined the mex-1.4.1.jar, I found a "suspicious" file module.xml in the META-INF folder. When I removed it, the problem was solved.
        Montag Rainer made changes -
        Comment [ Hallo,

        ich befinde mich vom 14.06.10 bis einschliesslich 02.07.10 im Urlaub.

        In dringenden Fällen wenden Sie sich bitte an meinen Kollegen aus den Projekten SWL-NG-CCM oder PSN.CCM.

        Viele Grüße

        Rainer Montag

        ]
        Hide
        shivendra tripathi added a comment -

        I have analyzed the issue and here is my finding.

        Issue is because we create configurationContext in every call instead of caching it once created. We cache ConfigurationContext in 1.5/ 1.6 so this issue is not reproducible there. Here the modified code. This is similar to axis2 1.5 where issue is fixed.

        ServiceClient#configureServiceClient

        if (configContext == null) {
        if (ListenerManager.defaultConfigurationContext == null)

        { configContext = ConfigurationContextFactory. createConfigurationContextFromFileSystem(null, null); ListenerManager.defaultConfigurationContext = configContext; createConfigCtx = true; }

        else

        { configContext = ListenerManager.defaultConfigurationContext; }

        }

        Above will fix generation of temp file for subsequent call. For deleting temp file on server start up call ServiceClient#cleanup().

        @Amila please review this so that I can provide the patch for previous versions (before 1.5) of axis2.

        Show
        shivendra tripathi added a comment - I have analyzed the issue and here is my finding. Issue is because we create configurationContext in every call instead of caching it once created. We cache ConfigurationContext in 1.5/ 1.6 so this issue is not reproducible there. Here the modified code. This is similar to axis2 1.5 where issue is fixed. ServiceClient#configureServiceClient if (configContext == null) { if (ListenerManager.defaultConfigurationContext == null) { configContext = ConfigurationContextFactory. createConfigurationContextFromFileSystem(null, null); ListenerManager.defaultConfigurationContext = configContext; createConfigCtx = true; } else { configContext = ListenerManager.defaultConfigurationContext; } } Above will fix generation of temp file for subsequent call. For deleting temp file on server start up call ServiceClient#cleanup(). @Amila please review this so that I can provide the patch for previous versions (before 1.5) of axis2.
        Hide
        shivendra tripathi added a comment -
        Show
        shivendra tripathi added a comment - I have updated my blog with above findings http://shivendra-tripathi.blogspot.com/2010/10/dealing-with-low-disk-space-problem.html
        Hide
        Ruwan Linton added a comment -

        Postponing to the next version

        Show
        Ruwan Linton added a comment - Postponing to the next version
        Ruwan Linton made changes -
        Fix Version/s 1.7 [ 12316136 ]
        Fix Version/s 1.6 [ 12313622 ]
        Hide
        P Karmooru added a comment -

        Hi,
        I am runnning into same issue. Is this fixed or is there any workaround for the issue. We have very less time , we dint know about the issue and we developed the webservice using Axis2 1.5. Now we need to fix this issue to move our code to production. Can someone please update me on this issue?

        Show
        P Karmooru added a comment - Hi, I am runnning into same issue. Is this fixed or is there any workaround for the issue. We have very less time , we dint know about the issue and we developed the webservice using Axis2 1.5. Now we need to fix this issue to move our code to production. Can someone please update me on this issue?
        Hide
        Matthias Gaiser added a comment -

        Hi P,
        since the temp files are created for all the modules (mar archives) which you have in your axis2 installation, a possible solution is to extract them.
        This way Axis2 has no need to extract them temporarily, therefore it does not create any temp files.
        Hope this helps.

        Show
        Matthias Gaiser added a comment - Hi P, since the temp files are created for all the modules (mar archives) which you have in your axis2 installation, a possible solution is to extract them. This way Axis2 has no need to extract them temporarily, therefore it does not create any temp files. Hope this helps.
        Hide
        Sagara Gunathunga added a comment -

        I tried to recreate this using 1.7.0 SNAPSHOTS but is seems impossible to me. For earlier versions number of workarounds already mentioned hence it's OK to mark this as fixed for 1.7.0 release. If any one can recreate this using 1.6.0/1 or 1.7.0 SNAPSHOTS please update this issue with relevant details.

        Show
        Sagara Gunathunga added a comment - I tried to recreate this using 1.7.0 SNAPSHOTS but is seems impossible to me. For earlier versions number of workarounds already mentioned hence it's OK to mark this as fixed for 1.7.0 release. If any one can recreate this using 1.6.0/1 or 1.7.0 SNAPSHOTS please update this issue with relevant details.
        Hide
        PV added a comment -

        Hello P,
        We are having a similar issue and need to resolve this ASAP. Can you please let me know how you resolved it. The .lck files do not get deleted.

        Show
        PV added a comment - Hello P, We are having a similar issue and need to resolve this ASAP. Can you please let me know how you resolved it. The .lck files do not get deleted.
        Hide
        Sagara Gunathunga added a comment -

        What is your Axis2 version ? As I mentioned in my last comment I can't reproduce this issue using 1.7.0 SNAPSHOTS and given instructions. Can you provide your environment and detail steps to reproduce this issue?

        It's necessary to reproduce this issue to find a proper solution.

        Show
        Sagara Gunathunga added a comment - What is your Axis2 version ? As I mentioned in my last comment I can't reproduce this issue using 1.7.0 SNAPSHOTS and given instructions. Can you provide your environment and detail steps to reproduce this issue? It's necessary to reproduce this issue to find a proper solution.
        Hide
        PV added a comment -

        Hi Sagara,
        I am on ver 1.5. I will try with 1.7.0 snapshot. Can you please let me know where you got it from? I tried https://builds.apache.org/job/Axis2/site/docs/installationguide.html
        but downloads link doesn't let me download.

        Show
        PV added a comment - Hi Sagara, I am on ver 1.5. I will try with 1.7.0 snapshot. Can you please let me know where you got it from? I tried https://builds.apache.org/job/Axis2/site/docs/installationguide.html but downloads link doesn't let me download.
        Show
        Sagara Gunathunga added a comment - You can download from here https://builds.apache.org/view/A-F/view/Axis2/job/Axis2/ws/axis2/modules/distribution/target/
        PV made changes -
        Comment [ Thanks! Just for clarification, if I installed 1.7.0 SNAPSHOT, will .lck/https://issues.apache.org/jira/secure/ViewProfile.jspa?name=sagaratmp directories be created at all? Or will it be deleted periodically? Please let know. ]
        Hide
        PV added a comment -

        Thanks! Just for clarification, if I installed 1.7.0 SNAPSHOT, will .lck/tmp directories be created at all? Or will it be deleted periodically? Please let know.

        Show
        PV added a comment - Thanks! Just for clarification, if I installed 1.7.0 SNAPSHOT, will .lck/tmp directories be created at all? Or will it be deleted periodically? Please let know.
        Hide
        PV added a comment -

        Hello P,
        Did you resolve this issue? If so, could you please tell me how to dealt with it?

        Thanks!

        Show
        PV added a comment - Hello P, Did you resolve this issue? If so, could you please tell me how to dealt with it? Thanks!
        Hide
        Sagara Gunathunga added a comment -

        Refer following post http://amilachinthaka.blogspot.com/2010/03/axis2-temp-files.html. I can see only one temporary file created for a module at any time.

        Show
        Sagara Gunathunga added a comment - Refer following post http://amilachinthaka.blogspot.com/2010/03/axis2-temp-files.html . I can see only one temporary file created for a module at any time.
        Hide
        Sagara Gunathunga added a comment -

        Still anyone facing to this issue on 1.7.0-SNAPSHOT version ? if not is it OK to mark this as fixed for 1.7.0 ?

        Show
        Sagara Gunathunga added a comment - Still anyone facing to this issue on 1.7.0-SNAPSHOT version ? if not is it OK to mark this as fixed for 1.7.0 ?
        Hide
        Sagara Gunathunga added a comment -

        Mark as resolved.

        Show
        Sagara Gunathunga added a comment - Mark as resolved.
        Sagara Gunathunga made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Susan Sawczuk added a comment -

        Is 1.7.0 a released version? Is it stable? I currently am on Axis2 1.5.1. I tried to upgrade to Axis 1.6.2 and used the WSDL files to generate source code - but I can't get any of them to compile. (I don't do a lot of java programming). Are there instructions anywhere on how to upgrade from one version to the next? With Axis2 1.5.1, when I invoke an object in my JAR file, it copies the Jar file into the temp directory. The Jar file is large, so copying it in the temp directory is causing problems.

        Show
        Susan Sawczuk added a comment - Is 1.7.0 a released version? Is it stable? I currently am on Axis2 1.5.1. I tried to upgrade to Axis 1.6.2 and used the WSDL files to generate source code - but I can't get any of them to compile. (I don't do a lot of java programming). Are there instructions anywhere on how to upgrade from one version to the next? With Axis2 1.5.1, when I invoke an object in my JAR file, it copies the Jar file into the temp directory. The Jar file is large, so copying it in the temp directory is causing problems.
        Hide
        Ion Galoi added a comment -

        I've tried the 1.7.0-SNAPSHOT and i can still reproduce the bug : for every call to the WS client it downloads int tmp a copy of axi2.jar [ and writes in log : INFO: Deploying module: addressing-1.7.0-20130619.000258-1435 ], at next run of the client the old axis2-tmp-* folder is cleaned and new one appears, so if i have my client deployed under a server and the server restarts once a year - i have my tmp folder filled with these jar copies .

        Show
        Ion Galoi added a comment - I've tried the 1.7.0-SNAPSHOT and i can still reproduce the bug : for every call to the WS client it downloads int tmp a copy of axi2.jar [ and writes in log : INFO: Deploying module: addressing-1.7.0-20130619.000258-1435 ], at next run of the client the old axis2-tmp-* folder is cleaned and new one appears, so if i have my client deployed under a server and the server restarts once a year - i have my tmp folder filled with these jar copies .
        Hide
        Olivier Vanekem added a comment -

        I also had the same kind of issues of .tmp directories not cleanly removed using Axis/2 1.6.2 under Oracle Weblogic Application Server. What I did ultimately as a work around is create a shell script that looks which folder contains 'orphaned' AAR files and delete those folders with the .lck file linked to it. My script parses the axis tmp folders and look if the aar for version is in use by a user (the application server in fact), if not, it deletes the folder. Works for me.

        Below is my script:

        for entry in /tmp/axis2*.tmp
        do
        	echo "Checking $entry"
        	for jar in "$entry"/axis2*version-1.6.2.aar
        	do
        		echo "Found $jar"
        		if fuser -vu "$jar" 2> /dev/null 
        		then
        			echo "Will not delete $entry"
        		else 
        			echo "Will delete $entry"
        			rm -R "$entry"
        			rm "$entry".lck
        			break
        		fi 
        	done
        done
        
        Show
        Olivier Vanekem added a comment - I also had the same kind of issues of .tmp directories not cleanly removed using Axis/2 1.6.2 under Oracle Weblogic Application Server. What I did ultimately as a work around is create a shell script that looks which folder contains 'orphaned' AAR files and delete those folders with the .lck file linked to it. My script parses the axis tmp folders and look if the aar for version is in use by a user (the application server in fact), if not, it deletes the folder. Works for me. Below is my script: for entry in /tmp/axis2*.tmp do echo "Checking $entry" for jar in "$entry" /axis2*version-1.6.2.aar do echo "Found $jar" if fuser -vu "$jar" 2> /dev/ null then echo "Will not delete $entry" else echo "Will delete $entry" rm -R "$entry" rm "$entry" .lck break fi done done
        Hide
        Ashleigh Gordon added a comment -

        This is still occuring in 1.7. In class org.apache.axis2.deployment.util.Utils there is a method called getURLsForAllJars(URL url, File tmpDir). This is what is creating the jar files in the temp directory. This is called by the method createClassLoader in the same class. I don't understand why the classloader first needs to copy the jar file over to the temp directory, why can't it simply load the classes from where the jar currently sits? There is a parameter on the createClassLoader method (boolean extractJars) that controls whether to create the jar files in the temp directory, from what I can see this is always set to true. Could this parameter perhaps be set to a configuration parameter?

        Show
        Ashleigh Gordon added a comment - This is still occuring in 1.7. In class org.apache.axis2.deployment.util.Utils there is a method called getURLsForAllJars(URL url, File tmpDir). This is what is creating the jar files in the temp directory. This is called by the method createClassLoader in the same class. I don't understand why the classloader first needs to copy the jar file over to the temp directory, why can't it simply load the classes from where the jar currently sits? There is a parameter on the createClassLoader method (boolean extractJars) that controls whether to create the jar files in the temp directory, from what I can see this is always set to true. Could this parameter perhaps be set to a configuration parameter?
        Hide
        C. Brian Cox added a comment -

        I will be out of the office, November 26th - 29th on vacation and holiday. While away I will have limited access to e-mail. I will return to the office Monday, December 2nd.

        Sorry for the inconvenience.

        Brian

        Show
        C. Brian Cox added a comment - I will be out of the office, November 26th - 29th on vacation and holiday. While away I will have limited access to e-mail. I will return to the office Monday, December 2nd. Sorry for the inconvenience. Brian
        Hide
        Cristiano Santos added a comment -

        Any news on that issue? It's still an active source of problems and there's no new Axis release since 2012.
        Thanks

        Show
        Cristiano Santos added a comment - Any news on that issue? It's still an active source of problems and there's no new Axis release since 2012. Thanks
        Hide
        Susan Sawczuk added a comment -

        We gave up on it.
        We periodically reboot the server and clean out the jar files.

        From: "Cristiano Santos (JIRA)" <jira@apache.org>
        To: ssawczuk@lakelandcc.edu
        Date: 02/11/2014 11:01 AM
        Subject: [jira] [Commented] (AXIS2-3919) Temp folder being filled
        with files. Running out of disk space.

        [
        https://issues.apache.org/jira/browse/AXIS2-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897954#comment-13897954
        ]

        Cristiano Santos commented on AXIS2-3919:
        -----------------------------------------

        Any news on that issue? It's still an active source of problems and
        there's no new Axis release since 2012.
        Thanks

        as our production servers would run out of disk space.
        axis2-1.4 and rampart-1.3.
        configure the client stub before making the call to our service.
        folder (see below)
        windows based but linux based. the files get put in /tmp/_axis2 folder.


        This message was sent by Atlassian JIRA
        (v6.1.5#6160)

        Show
        Susan Sawczuk added a comment - We gave up on it. We periodically reboot the server and clean out the jar files. From: "Cristiano Santos (JIRA)" <jira@apache.org> To: ssawczuk@lakelandcc.edu Date: 02/11/2014 11:01 AM Subject: [jira] [Commented] ( AXIS2-3919 ) Temp folder being filled with files. Running out of disk space. [ https://issues.apache.org/jira/browse/AXIS2-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897954#comment-13897954 ] Cristiano Santos commented on AXIS2-3919 : ----------------------------------------- Any news on that issue? It's still an active source of problems and there's no new Axis release since 2012. Thanks as our production servers would run out of disk space. axis2-1.4 and rampart-1.3. configure the client stub before making the call to our service. folder (see below) windows based but linux based. the files get put in /tmp/_axis2 folder. – This message was sent by Atlassian JIRA (v6.1.5#6160)
        Hide
        Cristiano Santos added a comment -

        Too bad. So it means there won't be any fix on that?

        Show
        Cristiano Santos added a comment - Too bad. So it means there won't be any fix on that?
        Hide
        Susan Sawczuk added a comment -

        I certainly don't have any control over it.
        I am just a user of Axis - not a developer.

        Sue

        From: "Cristiano Santos (JIRA)" <jira@apache.org>
        To: ssawczuk@lakelandcc.edu
        Date: 02/11/2014 11:51 AM
        Subject: [jira] [Commented] (AXIS2-3919) Temp folder being filled
        with files. Running out of disk space.

        [
        https://issues.apache.org/jira/browse/AXIS2-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898009#comment-13898009
        ]

        Cristiano Santos commented on AXIS2-3919:
        -----------------------------------------

        Too bad. So it means there won't be any fix on that?

        as our production servers would run out of disk space.
        axis2-1.4 and rampart-1.3.
        configure the client stub before making the call to our service.
        folder (see below)
        windows based but linux based. the files get put in /tmp/_axis2 folder.


        This message was sent by Atlassian JIRA
        (v6.1.5#6160)

        Show
        Susan Sawczuk added a comment - I certainly don't have any control over it. I am just a user of Axis - not a developer. Sue From: "Cristiano Santos (JIRA)" <jira@apache.org> To: ssawczuk@lakelandcc.edu Date: 02/11/2014 11:51 AM Subject: [jira] [Commented] ( AXIS2-3919 ) Temp folder being filled with files. Running out of disk space. [ https://issues.apache.org/jira/browse/AXIS2-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898009#comment-13898009 ] Cristiano Santos commented on AXIS2-3919 : ----------------------------------------- Too bad. So it means there won't be any fix on that? as our production servers would run out of disk space. axis2-1.4 and rampart-1.3. configure the client stub before making the call to our service. folder (see below) windows based but linux based. the files get put in /tmp/_axis2 folder. – This message was sent by Atlassian JIRA (v6.1.5#6160)
        Hide
        Anton Khitrenovich added a comment - - edited

        We found a workaround for that.
        Actually, the files are deployed to the temp folder each time AXIS configuration context is created. Also, it appears that the generated Stub can accept existing configuration object via the constructor. So, the following Spring configuration helped us to solve the issue (irrelevant bean and class names dropped):

        <bean id="....Stub" factory-bean="...." factory-method="...." scope="request">
        	<!-- this next element effects the proxying of the surrounding bean, 
        		needed because .... will try to set the stub out of request scope -->
        	<aop:scoped-proxy/>
        	<constructor-arg index="0" >
        		<!-- The WS stub is created here, and passed to the factory-method of ... as a parameter -->
        		<bean class="com......ws.....Stub" scope="prototype">
        			<constructor-arg ref="axisConfigContext" />
        		</bean>
        	</constructor-arg>
        </bean>
        	
        <!-- Exists to avoid deployment of axis jar into temp dir for each request. See AXIS2-3919 for more details. -->
        <bean id="axisConfigContext" 
        		class="org.apache.axis2.context.ConfigurationContextFactory" 
        		factory-method="createConfigurationContextFromFileSystem">
        	<constructor-arg index="0"><null /></constructor-arg>
        	<constructor-arg index="1"><null /></constructor-arg>
        </bean>
        
        Show
        Anton Khitrenovich added a comment - - edited We found a workaround for that. Actually, the files are deployed to the temp folder each time AXIS configuration context is created. Also, it appears that the generated Stub can accept existing configuration object via the constructor. So, the following Spring configuration helped us to solve the issue (irrelevant bean and class names dropped): <bean id= "....Stub" factory-bean= "...." factory-method= "...." scope= "request" > <!-- this next element effects the proxying of the surrounding bean, needed because .... will try to set the stub out of request scope --> <aop:scoped-proxy/> <constructor-arg index= "0" > <!-- The WS stub is created here, and passed to the factory-method of ... as a parameter --> <bean class= "com......ws.....Stub" scope= "prototype" > <constructor-arg ref= "axisConfigContext" /> </bean> </constructor-arg> </bean> <!-- Exists to avoid deployment of axis jar into temp dir for each request. See AXIS2-3919 for more details. --> <bean id= "axisConfigContext" class= "org.apache.axis2.context.ConfigurationContextFactory" factory-method= "createConfigurationContextFromFileSystem" > <constructor-arg index= "0" >< null /></constructor-arg> <constructor-arg index= "1" >< null /></constructor-arg> </bean>

          People

          • Assignee:
            Unassigned
            Reporter:
            Sujay Chauhan
          • Votes:
            15 Vote for this issue
            Watchers:
            20 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development