search

me0wster / javamelody

Automatically exported from code.google.com/p/javamelody
0 stars 0 forks source link

Javamelody should not use always the same directory for writing output files #240

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
javamelody seems to use java.io.tmpdir/javamelody for writing its output files.
However, this is causing problems when two different users start application 
servers (which is quite common, if you think of a multi-user development 
environment, where each user uses its own application server).

I suggest to not use java.io.tmpdir anymore in favor of 
(File)servletContext.getAttribute("javax.servlet.context.tempdir") which will 
not only fix this issue but also being a more compatible approach at all.

What steps will reproduce the problem?
1. Deploy a javamelody enabled application to an application server
2. Start the application
3. Stop the application server
4. Change OS user
5. Start application server with that user
6. Start javamelody enabled application

What version of the product are you using? On what application server, JDK,
operating system?
Linux, Java 6 U25 64bit, Resin 4.0

java.io.IOException: JavaMelody directory can't be created: 
/tmp/javamelody/myapplication
        at net.bull.javamelody.CounterStorage.writeToFile(CounterStorage.java:72)
        at net.bull.javamelody.Counter.writeToFile(Counter.java:861)
        at net.bull.javamelody.Collector.stop(Collector.java:834)
        at net.bull.javamelody.FilterContext.destroy(FilterContext.java:314)
        at net.bull.javamelody.MonitoringFilter.destroy(MonitoringFilter.java:138)
        at com.caucho.server.dispatch.FilterManager.destroy(FilterManager.java:257)
        at com.caucho.server.webapp.WebApp.stop(WebApp.java:4764)
        at com.caucho.server.webapp.WebApp.destroy(WebApp.java:4811)
        at com.caucho.env.deploy.DeployController.destroyInstance(DeployController.java:786)
        at com.caucho.env.deploy.DeployController.stopImpl(DeployController.java:770)
        at com.caucho.env.deploy.AbstractDeployControllerStrategy.stop(AbstractDeployControllerStrategy.java:85)
(...)

Original issue reported on code.google.com by mineral_...@gmx.de on 8 Aug 2012 at 8:10

GoogleCodeExporter commented 9 years ago 
More than 3 month passed since the opening of this issue.
Is there any estimation when a fix can be expected?
(possible simple solution is offered in the issue description)

I would really like to see javamelody in our qa/production systems but this 
issue prevents us from doing so.

Original comment by mineral_...@gmx.de on 14 Nov 2012 at 8:11

GoogleCodeExporter commented 9 years ago 
Yes, and my free time is short.
By the way, do you know the Donate page [1] and FreedomSponsors [2]?

Otherwise, have you thought of just using the "storage-directory" javamelody 
parameter to store the files in other directory [3]? It may make this issue a 
minor one.

[1] http://code.google.com/p/javamelody/wiki/Donate
[2] http://www.freedomsponsors.org/
[3] http://code.google.com/p/javamelody/wiki/UserGuide#6._Optional_parameters

Original comment by evernat@free.fr on 14 Nov 2012 at 10:38

GoogleCodeExporter commented 9 years ago 
Hi,
Your code can also be written as 
"filterConfig.getServletContext().getAttribute(ServletContext.TEMPDIR)", where 
ServletContext.TEMPDIR equals "javax.servlet.context.tempdir".

For example in Tomcat, the following code will return a File named 
"../work/Catalina/localhost/mywebapp", which is a directory where Tomcat stores 
compiled JSP.
This directory is rarely used by developers, which use "java.io.tmpdir" in 
general.

Given that there are compiled JSP, developers and operations people (including 
myself) often blindly delete this work directory to clean-up before a new 
deployment and to be sure to deploy the upgraded webapp. So it would probably 
not be good to store our files in the work directory by default.

By the way, it would be a very important change for all javamelody users. Those 
users are used to find the files in the temp directory and many have a lot of 
historical data which risk to be forgotten if the default storage directory 
changes. So such a change should be made only for a critical reason.

Finally, it seems better to store the files in the temp directory of the server 
by default (if the "storage-directory" parameter is undefined), than in the 
work directory. And this issue is "Won't fix".

There are probably workarounds for such an issue: "chmod" or "chown" commands 
on the temp directory, or use of the "storage-directory" javamelody parameter.
Thanks for the idea anyway.

Original comment by evernat@free.fr on 15 Dec 2012 at 3:58