V1.2.8: RollingFileAppender sometimes loses files when logging across Storage Area Network (SAN)

["Karr, David" <da...@wamu.net>]

I wrote about this a few weeks ago, but I've since gotten more specific
information about this problem.

We have a situation where we're using the RollingFileAppender, and
writing to log files on a Storage Area Network (SAN).  We have two
hosts, clustered with Microsoft Clustering, such that only the active
host can see the SAN drive.

What we see is that after a run of tests, where there should be a
consecutive set of log files, there are some missing, both in file name
and content.

We tried doing a similar test, by locating the log files on the local
host, and not on the SAN, and we no longer see this problem.

So, is there some aspect of the RollingFileAppender that might be
configurable to help alleviate this?  Is there a different Appender that
might not be susceptible to this?

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

Re: V1.2.8: RollingFileAppender sometimes loses files when logging across Storage Area Network (SAN)

[Jacob Kjome <ho...@visi.com>]

Quoting Curt Arnold <ca...@apache.org>:
> Unfortunately, the CVS HEAD is not binary
> compatible at this time with log4j 1.2.

I'd say it is pretty darned close.  It works with LogWeb, which excercises Log4j
internals quite a bit.  There's still work to do, but I don't think this is
nearly the problem it was even 1 month ago.


Jake

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

Re: V1.2.8: RollingFileAppender sometimes loses files when logging across Storage Area Network (SAN)

[Curt Arnold <ca...@apache.org>]

On Aug 2, 2005, at 6:41 PM, Karr, David wrote:
>
> So, is there some aspect of the RollingFileAppender that might be
> configurable to help alleviate this?  Is there a different Appender  
> that
> might not be susceptible to this?


The log4j 1.2 implementation (if I remember correctly) is susceptible  
to file loss if the rename operation fails.  The implementation in  
the CVS HEAD should be more resilient and should avoid rolling over  
if there is a failure in any of the renaming operations or on opening  
the new log file.  Unfortunately, the CVS HEAD is not binary  
compatible at this time with log4j 1.2.  However, if you could test  
the CVS HEAD under the same conditions and see if the problem occurs  
there, we can determine if it is a known problem or something new. 

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