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 "Opaczewski, Greg" <GO...@orbitz.com> on 2007/02/21 05:32:12 UTC
log4j 1.2.15
Is it possible to get a 1.2.15 sometime soon? We have some performance
issues that have recently become critical that may be solved by a switch
to async logging, but I was waiting on a patch for this issue first:
http://issues.apache.org/bugzilla/show_bug.cgi?id=41186
thanks-
Greg
RE: log4j 1.2.15
Posted by "Opaczewski, Greg" <GO...@orbitz.com>.
That's correct, I was asking about the 1.2.15 release. Can you provide
an ETA for this? I'm just trying to gauge whether I can wait for the
official release.
thanks-
Greg
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Wednesday, February 21, 2007 1:45 AM
> To: Log4J Developers List
> Subject: Re: log4j 1.2.15
>
>
> On Feb 20, 2007, at 10:32 PM, Opaczewski, Greg wrote:
>
> > Is it possible to get a 1.2.15 sometime soon? We have some
> > performance issues that have recently become critical that may be
> > solved by a switch to async logging, but I was waiting on a patch
> > for this issue first:
> >
> >
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=41186
> >
> >
>
> I'm interpreting that you meant that you are waiting on a release
> with the patch for that issue. The issue itself has been fixed in
> the SVN which you acknowledged in your comment on the issue. If the
> patch didn't fix the problem, please reopen the bug.
>
> I've added a few additional dependencies to the 1.2.15 release bug
> (40951). If anyone has a favorite bug that should go into 1.2.15,
> please mention it or add it as a dependency on the bug.
>
> I've been looking at the bugs around ThrowableInformation. I'm torn
> whether to:
>
> a) Eliminate the existing VectorWriter class and pass a PrintWriter
> wrapping a StringWriter, then break the StringBuffer at line
> separator boundaries.
>
> b) Replace NullWriter with StringWriter and check if anything got
> handed off to the StringWriter on all the overloaded print calls.
>
> The first approach would do the right thing if you had a
> printStackTrace that did use a lot of the unsupported methods or the
> print() methods. However, it would be a radically different code
> path. The second would have the same code path as long as you used
> the supported methods but would have ugly behavior if you did use
> PrintWriter.write(int) a lot (each character as a separate String in
> the array). Still writing test cases around ThrowableInformation to
> capture the current behavior at the moment.
>
> Applying the updated ASF Source and Copyright Policy is required in
> any new release.
>
> ---------------------------------------------------------------------
> 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: log4j 1.2.15
Posted by Endre Stølsvik <En...@Stolsvik.com>.
> I've added a few additional dependencies to the 1.2.15 release bug
> (40951). If anyone has a favorite bug that should go into 1.2.15,
> please mention it or add it as a dependency on the bug.
Last time I looked at the code, the NDC was implemented using a
"homebrewed" ThreadLocal (static map keyed on Thread)
When checking out the code from svn, I see that the trunk (1.3) uses
ThreadLocal, while the 1.2 branch uses the old stuff.
This "homebrewed" approach has some serious disadvantages, in particular
that it is prone to be filled with garbage if one forgets to
NDC.remove() (or one is thrown out before this for some reason) (and
that this again leads to whole classloaders of classes that can never be
released), but more seriously, it sucks performance wise (full
contention for all codepaths using the NDC, both on the NDC-push/pop,
but also on the appender/formatter side).
ThreadLocal from java >=1.3 reverses the Map, using a Map within the
Thread, keying on the ThreadLocal. This then doesn't need synching.
There is, however, still an issue with leaking classloaders
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531), but not
worse than it is now for the NDC. (There exists a patch that fixes this,
which apparently will be included at some point. Please vote on the
sun-bug if you find it interesting, check the comment about Tomcat's
leaking on webapp reloads).
Basically, what I'm asking for is that the NDC in trunk is simply
backported to the 1.2 branch. There should be no other effects of this
other than speed increases; ThreadLocal was in java from 1.2 on.
PS: The MDC have similar problems - and could also benefit from simply
using ThreadLocal for the storage of the Hashtable that holds the MDC
mappings.
Kind regards,
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.2.15
Posted by Curt Arnold <ca...@apache.org>.
On Feb 20, 2007, at 10:32 PM, Opaczewski, Greg wrote:
> Is it possible to get a 1.2.15 sometime soon? We have some
> performance issues that have recently become critical that may be
> solved by a switch to async logging, but I was waiting on a patch
> for this issue first:
>
>
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=41186
>
>
I'm interpreting that you meant that you are waiting on a release
with the patch for that issue. The issue itself has been fixed in
the SVN which you acknowledged in your comment on the issue. If the
patch didn't fix the problem, please reopen the bug.
I've added a few additional dependencies to the 1.2.15 release bug
(40951). If anyone has a favorite bug that should go into 1.2.15,
please mention it or add it as a dependency on the bug.
I've been looking at the bugs around ThrowableInformation. I'm torn
whether to:
a) Eliminate the existing VectorWriter class and pass a PrintWriter
wrapping a StringWriter, then break the StringBuffer at line
separator boundaries.
b) Replace NullWriter with StringWriter and check if anything got
handed off to the StringWriter on all the overloaded print calls.
The first approach would do the right thing if you had a
printStackTrace that did use a lot of the unsupported methods or the
print() methods. However, it would be a radically different code
path. The second would have the same code path as long as you used
the supported methods but would have ugly behavior if you did use
PrintWriter.write(int) a lot (each character as a separate String in
the array). Still writing test cases around ThrowableInformation to
capture the current behavior at the moment.
Applying the updated ASF Source and Copyright Policy is required in
any new release.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org