You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Ben Reif <be...@gmail.com> on 2010/04/14 14:43:02 UTC

Large number of files written to temp folder

My application needs to create different ConfigurationContext objects to
pass into the ServiceClient to invoke different Web Services. It seems that
every time this is done Axis2 creates a lot of *.mar files in a temp folder.
This reduces performance and also takes up a lot of disk space. I’ve read
several other related posts that indicate that it does this to try to
resolve other *.jar files that may be located inside the *.mar files, but
couldn’t this all be done in memory rather then constantly writing to and
then reading from the file system?



To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
class to change the way that the ‘deploymentClassLoader’ variable is created
like this:



Old code:



URL moduleurl = new URL(moduleDir, fileUrl);

ClassLoader deploymentClassLoader = Utils.createClassLoader(new
URL[]{moduleurl},



axisConfig.getModuleClassLoader(),


                                                            true,


(File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));



New Code:



URL moduleurl = new URL(moduleDir, fileUrl);

ArrayList<String> embeddedJars =
(ArrayList<String>)Utils.findLibJars(moduleurl);

ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
{moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());



By changing the code to look like this, we can do everything in memory
rather then writing temporary files to the file system. I wanted to see what
people think about this solution and if the DeploymentEngine might be able
to be fixed in the next release?



Thanks,

Ben

Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@axis.apache.org
For additional commands, e-mail: java-user-help@axis.apache.org


Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Re: Large number of files written to temp folder

Posted by Amila Suriarachchi <am...@gmail.com>.
I think you can avoid this by deploying services and modules in expanded
mode.
i.e just unzip the .mar file and put under modules folder.

thanks,
Amila.

On Wed, Apr 14, 2010 at 6:13 PM, Ben Reif <be...@gmail.com> wrote:

> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben
>



-- 
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/

Re: Large number of files written to temp folder

Posted by Andreas Veithen <an...@gmail.com>.
Some quick comments about this:

1. Using a DeploymentClassLoader with embeddedJars has a drastic
performance impact. It is not visible in all scenarios, but when it
shows up, it makes Axis2 look ridiculous. Therefore, using this as the
default behavior would be a bad idea.

2. Creating a ConfigurationContext is a heavy operation that should be
done once at application startup. If you create a new
ConfigurationContext for every request, then you should change your
code.

3. It would be interesting to know how URLClassLoader handles the case
where a URL points to an embedded JAR.

4. Axis2 is not the only framework that uses deployable artifacts with
embedded JARs. EARs, WARs and OSGi bundles also fall into this
category. It would be interesting to check how servlet containers,
application servers or OSGi runtimes handle this.

Andreas

On Wed, Apr 14, 2010 at 14:43, Ben Reif <be...@gmail.com> wrote:
> My application needs to create different ConfigurationContext objects to
> pass into the ServiceClient to invoke different Web Services. It seems that
> every time this is done Axis2 creates a lot of *.mar files in a temp folder.
> This reduces performance and also takes up a lot of disk space. I’ve read
> several other related posts that indicate that it does this to try to
> resolve other *.jar files that may be located inside the *.mar files, but
> couldn’t this all be done in memory rather then constantly writing to and
> then reading from the file system?
>
>
>
> To fix this I’ve extended the URLBasedAxisConfigurator and have overridden
> the loadRepositoryFromURL(URL repoURL) method from the DeploymentEngine
> class to change the way that the ‘deploymentClassLoader’ variable is created
> like this:
>
>
>
> Old code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ClassLoader deploymentClassLoader = Utils.createClassLoader(new
> URL[]{moduleurl},
>
>
>                                                         axisConfig.getModuleClassLoader(),
>
>                                                             true,
>
>
> (File)axisConfig.getParameterValue(Constants.Configuration.ARTIFACTS_TEMP_DIR));
>
>
>
> New Code:
>
>
>
> URL moduleurl = new URL(moduleDir, fileUrl);
>
> ArrayList<String> embeddedJars =
> (ArrayList<String>)Utils.findLibJars(moduleurl);
>
> ClassLoader deploymentClassLoader = new DeploymentClassLoader(new URL[]
> {moduleurl}, embeddedJars, axisConfig.getModuleClassLoader());
>
>
>
> By changing the code to look like this, we can do everything in memory
> rather then writing temporary files to the file system. I wanted to see what
> people think about this solution and if the DeploymentEngine might be able
> to be fixed in the next release?
>
>
>
> Thanks,
>
> Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org