I don't recall (emphasis on recall) seeing anything about
async'ing the compression. Can you provide me some links to
refresh my memory? I think this is a good idea, it's just a
reasonable chunk of work, and async stuff can be complicated.
After completing the refactoring of the pattern code, I went back
and read the mailing list archives and open bug reports on the
rolling file appenders. Async compression was raised in http://
marc.theaimsgroup.com/?l=log4j-user&m=109144092332509&w=2 last
August. The issues raised there did seem legitimate and difficult
to address with the current interface definitions.
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. 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? (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.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
