If you want to reload log4j configuration it is because you have made a change let us say to debug a specific issue appearing right now in production. Is there a real need to be monitoring the file for changes? Wouldn't it be better to use resources just by the time we really want a reload?
Tomcat provides a mechanism to allow dynamic reloading and JBoss ships with the solution already integrated (meaning the standard installation will check the file to reload it every so often)
The point is they do not provide a simple admin link to force reloading which in my opinion goes against the natural process: change configuration file, save it and expect the changes. Just in order to avoid a final step "push the changes" is not enough in my opinion. Apache Server knows that very well, you can reload your configuration but on demand.
On demand reloading has a big advantage: You use resources just when you need them. With that approach we could avoid performance problems: read using "reloadable" for in production for tomcat 7 or memory leaks which I have to say have hit my teams both in JBoss and Tomcat environments.
I see no big deal on allowing an on demand reloading but while I wait for that day I prefer to reload the application context after changing the log4j properties file:
$ vi tomcat/webapps/my-app/WEB-INF/classes/log4j.properties $ touch tomcat/webapps/my-app/WEB-INF/web.xml
And yes you must do this with caution in production as you kick out some of your users from that node in your cluster or even worst, you could be putting your service down for some seconds (Yes Tomcat is extremely fast especially when you avoid complicated processes at "Servlet Listener" time)
This is clearly far from ideal as the issue you are trying to debug might not be happening again after you restart your application. So think twice before deciding to increase log level in production and think more about creating load test scenarios in integration and staging environments.
No comments:
Post a Comment