You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <wo...@adobe.com> on 2005/07/14 23:32:45 UTC
Bug #24159
Does anyone want to weigh in on this bug? Besides adding TRACE, it looks
like this is the most controversial bug fix.
http://issues.apache.org/bugzilla/show_bug.cgi?id=24159
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Bug #24159
Posted by Elias Ross <er...@m-qube.com>.
On Thu, 2005-07-14 at 17:25 -0500, Curt Arnold wrote:
>
> I agree that it is too potentially disruptive to attempt in 1.2.x.
> I'm not ready to commit to doing it in 1.3, however. log4j currently
> does fairly coarse synchronization which has been raised as an issue
> repeatedly (the whole concurrent appender proposal, for example) and
> refactoring synchronization would likely be a 2.0.x type of change.
I'm the person who filed the bug 1 1/2 years ago...
Despite having to wait, I agree that 1.2 is probably too early and
likely too disruptive. You would have to change the synchronization
behavior of AppenderSkeleton, which would subtly break classes that
extend AppenderSkeleton or its subclasses.
In 1.3, you have already cleaned up the coarse locking in the Category
(Logger) class with respect to adding and removing appenders by using a
read-write lock. This is a step in the right direction. My concurrent
appender uses the same read-write class and my AppenderSkeleton (called
ConcurrentAppender) is nearly identical in implementation to the
original, except for a few additional finer-locked objects.
For 1.3, it would be reasonable to include a concurrent appender tree.
In addition to having better performance and less coarse locking (and no
dead-locks), it would be a reasonable parent class for network- and
JDBC-based loggers. Eventually, they could form the basis of appenders
in a future release.
>>From working with application services (namely JBoss) for over two
years, it is imperative to have a logging subsystem that is dead-lock
free and high-performance on two and four-processor machines. Although,
we do not log a huge volume typically, it is necessary for debugging a
live a system. My original complaint came from debugging a third-party
library on a application system.
I would at least appreciate people code review my work. The subclasses
of WriterAppender (for example, my ConsoleAppender.java and
FileAppender.java) are identical except for the package name. If you
are planning on breaking compatibility ("cleaning up") many existing
classes for 1.3, please consider moving to a concurrent model. If not,
please include it as a sub-tree.
Many thanks,
Elias
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Bug #24159
Posted by Curt Arnold <ca...@houston.rr.com>.
On Jul 14, 2005, at 5:01 PM, Paul Smith wrote:
> That is a biggie isn't it...
>
> I feel quite a bit uncomfortable about attempting this for 1.2.x.
> My rationale is that 1.2.x has been around a LONG time now. I know
> "better the devil you know" is not a great way to develop software,
> but in this case I think we may end up creating more problems for
> our users than we solve. I hedge towards just making sure this
> problem can't happen in the 1.3.x series (which I believe it can't
> with the Read/Write lock stuff Ceki did).
>
> Paul
I agree that it is too potentially disruptive to attempt in 1.2.x.
I'm not ready to commit to doing it in 1.3, however. log4j currently
does fairly coarse synchronization which has been raised as an issue
repeatedly (the whole concurrent appender proposal, for example) and
refactoring synchronization would likely be a 2.0.x type of change.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Bug #24159
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hey,
I couldn't have said it better than Paul: I agree with everything he says.
This is not a good 1.2 candidate, but should be a requirement for 1.3.0.
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
yoavsh@sloan.mit.edu / yoavs@computer.org
> -----Original Message-----
> From: Paul Smith [mailto:psmith@aconex.com]
> Sent: Thursday, July 14, 2005 6:02 PM
> To: Log4J Developers List
> Subject: Re: Bug #24159
>
> That is a biggie isn't it...
>
> I feel quite a bit uncomfortable about attempting this for 1.2.x. My
> rationale is that 1.2.x has been around a LONG time now. I know
> "better the devil you know" is not a great way to develop software,
> but in this case I think we may end up creating more problems for our
> users than we solve. I hedge towards just making sure this problem
> can't happen in the 1.3.x series (which I believe it can't with the
> Read/Write lock stuff Ceki did).
>
> Paul
>
> On 15/07/2005, at 7:32 AM, Mark Womack wrote:
>
> > Does anyone want to weigh in on this bug? Besides adding TRACE, it
> > looks
> > like this is the most controversial bug fix.
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=24159
> >
> > -Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Bug #24159
Posted by Paul Smith <ps...@aconex.com>.
That is a biggie isn't it...
I feel quite a bit uncomfortable about attempting this for 1.2.x. My
rationale is that 1.2.x has been around a LONG time now. I know
"better the devil you know" is not a great way to develop software,
but in this case I think we may end up creating more problems for our
users than we solve. I hedge towards just making sure this problem
can't happen in the 1.3.x series (which I believe it can't with the
Read/Write lock stuff Ceki did).
Paul
On 15/07/2005, at 7:32 AM, Mark Womack wrote:
> Does anyone want to weigh in on this bug? Besides adding TRACE, it
> looks
> like this is the most controversial bug fix.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=24159
>
> -Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org