关于log4j的log4j:ERROR Failed to rename错误的一些感受

     今天，运行了几个月的应用，发现从4月1日起，日志都没有记录。一开始，以为是病毒，或者是黑客什么的，毕竟，在网络上难免的，而且以前也发生过这样的事情。

     后来，打开了tomcat的日志时候，发现了log4j:ERROR Failed to rename的错误，初步怀疑是windows文件占用的问题。

     决定，重新启动服务，看看反馈效果。效果要明天才能看到呢。

     上网找了一下相应的文章，看到  http://duanni.iteye.com/blog/177271  也说了log4j的同样的问题，从而确认了自己的看法没有错，这是log4j再rename时候的一个bug。

 

     我的应用环境是：

     windows2003 server

     MS SQL Server 2005

     jdk 1.5

     log4j 版本不详

 

     问题描述：

     发生在启动应用几个月以后，再也不会记录日志了。前几个月的日志还都正常保存着。

    

     分析问题：

     经过上面那个blog的提示，我认为会是因为windows系统将文件放入内存，从而提高读写效率，但也使得文件无法重命名，无法删除导致。

     再进一步思考，log4j会有这么低级的错误吗？毕竟是很多人使用在很多应用上的开源工具了，这些问题都没有处理吗？

     经过在linux上的实验发现，linux下的文件处理策略与windows不同，

     windows为了提高文件读写效率，将经常使用的文件，放入内存，从而提高使用效率，但在系统底层认为还有必要保留文件时，文件是不可以被修改名称和删除的。类似的问题在我们经常删除文件夹时，系统报告文件被占用，无法删除是同样的道理。

     linux的处理机制不同，在linux中，如果你打开了一个文件，在文件没有关闭的情况下，你是可以删除的，但当你不保存时关闭文件后，文件会不在系统中存在了。

     这是两种不同的文件处理策略，很难说谁好谁坏，针对不同的用户，实现不同的策略，没有任何可异议的地方，但正是因为这种不同的策略，产生了，同样的java代码，在不同的系统中，会有不同的表现。

 

     解决问题：

     对于问题的解决，上面引用的blog中直接修改了log4j的原文件，而这种方式从根本上解决了问题的发生。我需要补充一点的是，当log4j拷贝或改名出现问题时，log4j仍然会清空原有日志文件，而即使是使用copy的方法，我们仍然无法预料操作系统会出现什么样的情况，不允许拷贝文件，也许类似的问题仍然会发生，所以，我们如果修改原文件，应该同时修改一下log4j这个处理策略的方面，避免日志没有被拷贝的情况下，被清空了（没有研究log4j代码，随后找到改哪里以后，我会补充上）。

    

     但如果我的人员，开发能力比较低下的时候，就可能会产生比较大的麻烦，恰恰，我的人员能力正好是这种问题。

     好在，我的应用是b/s系统，从而我想了另外一种技术上相对简单的处理策略：

     1.每天定时重新启动服务

     2.重新启动服务时，利用servlet的初始化方法，拷贝并清空原有日志文件

     3.不能清空文件时，不拷贝原有日志文件，等待下次处理

     3.改变log4j策略，使log4j不会自动生成每天日志文件，而是从头至尾就是一个文件

     这种方法等于自己实现了log4j的每天日志策略，同时避免了日志因为操作系统的问题，无法拷贝或改变名称时也要清除内容的问题。

评论

1 楼 h521999 2009-08-10  

这种方法个人感觉是肯定不行的，不治本