On May 23, 2005, at 11:54 PM, Paul Smith wrote:
August! Probably why I don't remember it. I don't remember last
week as it is... :) I love the idea of Asnyc roll/compress, as the
mail thread pointed out, a system can be blocking quite a while if
the log file is being compressed in a synchronous manner while
holding the appender lock. If no-one else has any objects this
will be a good feature.
I must admit thought thatIi'm not a fan of the change to the API of
'rollover()' to "rollover(List, List)". It doesn't seem very
satisfying, even if it does do the job intended.
Don't forget the StringBuffer, that is a bit of ugliness too. I
wanted to get RollingPolicy.rollover atomic (previously you had both
call both rollover and getActiveFileName and the RollingPolicy cached
the time of the rollover call to provide the active file name) and
wanted to have the RFA responsible for maintaining the thread (since
it has to be joined on close) and doing the actions that require the
active log file to be closed. Instead of the mutable parameters,
could have something like:
interface RollingPolicy {
RolloverDescriptor rollover() throws IOException;
}
interface RolloverDescriptor {
String getActiveFileName();
Action getSynchronousActions();
Action getAsynchronousActions();
}
The use of the Command pattern is good, but the api change doesn't
feel quite right. Should the sync actions just be execute()d by
the current thread, and then the runnables deferred to an
util.concurrent.Executor instance?
I think we need to use Thread for now, but would be good to
anticipate (or prototype) a util.concurrent.Executor implementation.
My use of join() in the RFA.rollover() and RFA.close() would need to
go. The join in RFA.rollover is to prevent a rollover from being
executed while compression tasks are still running. Instead of
joining, the previous async action could be asked if it were
completed and if not, a rollover would not be evaluated. Could have
an action action synchronize on itself while running and have the
close synchronize on any pending action to prevent it from completing
before any async compression is complete.
(That would be a dependency, but it is a good library, we can
execute them all synchronously if the library is not present). I'd
hate to see log4j grow just because we want to keep dependencies to
a minimum, otherwise the classic rule "Applications/Libraries
expand their scope until they can send mail" as we add features.
One day log4j will have a JDK 5.0 dependency and we can enjoy the
juicy util.concurrent library that got rolled into it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
