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.
--
Jess Holle
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?
Scott
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
