I think that conceptually and practically the old RFA and DRFA are
limited to being written to by a single process -- period. It should
simply be stated that all bets are off otherwise, use at your own risk,
etc -- and to use a new ChannelAppender-based appender instead.
How many outstanding issues do RFA and DRFA have once one limits oneself
to a single process? I'd hope that for *that* use case use of these
appenders themselves (as opposed to the trouble one can cause in
subclasses) would be safe from deadlocks, etc -- or could be made so.
Any improvement beyond this should be a non-goal for these old
appenders, but I'd hope to accomplish this goal.
Personally I see a whole class of logging wherein one simply does not
want multiple processes contributing to one file -- period. We ensure
this does not happen in our usage -- unless an errant user
mis-configures the system. I can see use cases for multiple-processes
writing to one file, but I'd personally rather avoid the extra
contention inherent in this.
Curt Arnold wrote:
> On Aug 7, 2009, at 2:16 AM, Scott Deboy wrote:
>> Is it possible to use the new implementation and provide the same
>> extension points that the old implementation provided?
> I don't think so, so much of the internals of RFA and DRFA were
> exposed that you can't change much without potentially breaking someone.
> Any appender that relies on renaming is going to trouble-prone and
> java.io doesn't provide any way to handle writes from multiple JVM's
> (which is the one of the major source of issues with all of the
> RFA's). To have a really robust appender that writes across files, I
> think something like MFA but rewritten to be based on java.nio would
> be needed. We could push it into log4j 1.x when it is ready as an
> alternative to RFA and DRFA. It would require JDK 1.4 to run, but I
> don't think it would prevent the rest of log4j to run on JDK 1.3.
> The base would be a ChannelAppender that would be the basis of
> java.nio based appenders like WriterAppender is for java.io appenders.
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logg... > For additional commands, e-mail: log4j-dev-help@logg...