DO NOT REPLY [Bug 13171] New: - Some little spelling mistakes and deprecation warnings

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13171>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13171

Some little spelling mistakes and deprecation warnings

           Summary: Some little spelling mistakes and deprecation warnings
           Product: Log4j
           Version: 1.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Other
        AssignedTo: log4j-dev <at> jakarta.apache.org
        ReportedBy: tilman.giese <at> gmx.de

I recently got the CVS code to compile from sources. Meanwhile I figured out
some little warnings which can easily be solved:

(1) When executing javadoc, I get the following warning: duplicate class: T. I
suppose you should add the package name to org/apache/log4j/jmx/T.java
(2) Javadoc complains about some spelling mistakes:

  (a) org/apache/log4j/Appender.java:76 should be  <at> since (not  <at>  since)

DO NOT REPLY [Bug 13099] - DOMConfigurator ignores category factory setting

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13099>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13099

DOMConfigurator ignores category factory setting

------- Additional Comments From asisser <at> lehman.com  2002-10-01 19:13 -------
I've noticed it too and this causes serious problems for me because I've 
subclassed the Logger class.  When the DOMConfigurator runs and tries to set 
the log level for specific categories, it ignores the categoryFactory and 
creates default log4j.Logger objects.  These choke my code when I go to load 
the appropriate Logger and cast it to my own Logger sub-class.  Not only is not 
setting the defaultFactory, it's not even using the LoggerFactory to create the 
Logger objects it needs during configuration.

A survey about handling bugs in open source projects

Hello all Log4j contributors,

I am conducting a survey about the way defects (or bugs-I use these two words
 interchangeably) are handled in open source software projects. It is
very easy to fill out. It consists of three short sections which can be
completed at once or in different sessions. The survey can be found in the
address:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

This survey includes questions that can be answered by developers,testers,
bug fixers, bug database owners, and project managers. I would greatly
appreciate if you could visit the above web page and fill out the survey.
I am sure you will find the questions very interesting and thought
provoking.  We need the help of all contributors of Log4j in the above roles
to understand how we can use bugs data collected in your project for
software engineering research.

Nowadays, there is a huge amount of bug data on the Internet collected
during the development of all open source products. A bug database include
useful information to identify high-risk, problem-prone modules
(components) in the software. It is also possible to measure these
problem-prone components using several complexity metrics (McCabe's
cyclomatic complexity, Halstead's metrics, etc.), since the source code is
available. If a characterization, which is generalizable across many
projects (sub-projects) could be made in terms of complexity, focused
quality improvement would become possible in the future projects. So far,
in the literature, there is quite amount of evidence that 80 percent of
the problems occur from 20 percent of the modules (or software
components), which gives hope toward tremendous quality increase, time

cvs commit: jakarta-log4j/src/xdocs documentation.xml download.xml

ceki        2002/10/02 09:29:08

  Modified:    src/xdocs Tag: v1_2-branch documentation.xml download.xml
  Log:
  Syncing CVS rep with what has been visible on the web page for some time now.

  Revision  Changes    Path
  No                   revision

  
  No                   revision

  
  1.15.2.4  +23 -6     jakarta-log4j/src/xdocs/documentation.xml

  Index: documentation.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-log4j/src/xdocs/documentation.xml,v
  retrieving revision 1.15.2.3
  retrieving revision 1.15.2.4
  diff -u -r1.15.2.3 -r1.15.2.4
  --- documentation.xml	5 Jul 2002 11:23:49 -0000	1.15.2.3
  +++ documentation.xml	2 Oct 2002 16:29:08 -0000	1.15.2.4
   <at>  <at>  -62,17 +62,34  <at>  <at> 
       <section name="Articles on log4j">
         <ul>

  -	<li><a href="http://www.vipan.com/htdocs/log4jhelp.html">Don't Use System.out.println!
  +	<p>
  +	  <li><a href="http://www.vipan.com/htdocs/log4jhelp.html">Don't Use System.out.println!

DomConfigurator Entity Resolver update

Guys,

I found a bug in the bug fix which stopped it working, the file attached
fixes this problem.

Paul Austin
Galdos Systems Inc.™
paustin <at> galdosinc.com
Tel: +1 (604) 484-2761
Fax: +1 (604) 484-2755
http://www.galdosinc.com/

Privileged or confidential information may be contained in this message. If
this message was not intended for you, destroy it and notify us immediately.
Opinions, conclusions, recommendations, and other information presented in
this message are not given or necessarily endorsed by my employer or firm.

--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe <at> jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help <at> jakarta.apache.org>

Proposed architecture changes to log4j for improved memory usage

I am currently on a project using log4j for the first time.  We're using
1.1.3.  I had many concerns with the amount of transient objects created
during logging to a DailyRollingFileAppender.  I refactored log4j making
memory usage improvements that I think could be very useful to log4j users.

One recent test showed 350MB of transient memory created by log4j to log 33
MB of data consisting of 33500 log entries; the number of transient objects
numbered in the millions and was uncountable by my tools.  The layout
pattern used was:

log4j.appender.R.layout.ConversionPattern=%d{MMM dd yyyy HH:mm:ss,SSS} %t %
-5p %c - %m%n

Without date formatting the total was ~275 MB.

I appreciate the functionality offered by this framework but I find it's
disregard for memory consumption disturbing.  I refactored it and I can now
run the same test generating only 4 MB of transient data and 105000
transient objects for the same 33 MB data set.  The remaining 4 MB and
objects are JDK deficiencies and can't be overcome easily:
1)  The JDK's Thread class stores it's name as a char[].  Every time
Thread.getName() is called that char[] is converted to a String resulting
in 2 new objects, the String and it's associated char[].  I am going to see
if I can get a message through to the Sun folks to look at this.  Of
course, this framework could store the name once in a local variable on
first lookup, but this assumes the Thread name will never change
2)  The sun.io.CharToByteSingleByte.convert method leaks a byte[1] every
time invoked.

This means for N messages logged, N * 3 objects are created from the JDK

Re: Proposed architecture changes to log4j for improved memory usage

Hi Chris,

Object reuse and optimizing memory usage was one of the themes I was
seriously considering for future log4j releases.

Your results are somewhat surprising. I knew memory usage could be
improved but hadn't realized the extent...

More comments below.

At 10:42 03.10.2002 -0500, Chris.Nokes <at> perficient.com wrote:
>I am currently on a project using log4j for the first time.  We're using
>1.1.3.  I had many concerns with the amount of transient objects created
>during logging to a DailyRollingFileAppender.  I refactored log4j making
>memory usage improvements that I think could be very useful to log4j users.
>
>One recent test showed 350MB of transient memory created by log4j to log 33
>MB of data consisting of 33500 log entries; the number of transient objects
>numbered in the millions and was uncountable by my tools.  The layout
>pattern used was:

Millions? Wow!

>log4j.appender.R.layout.ConversionPattern=%d{MMM dd yyyy HH:mm:ss,SSS} %t %
>-5p %c - %m%n
>
>Without date formatting the total was ~275 MB.

What happens with just %d (with nothing within the braces)? With %r?
With no time information?

RE: Proposed architecture changes to log4j for improved memory usage

Hi,
First of all - this was the most thought provoking message I'd seen on a
dev list for a long time, so thank you ;)

>Your results are somewhat surprising. I knew memory usage could be
>improved but hadn't realized the extent...

Same here.  But to preface, I value speed and reliability far far more
than memory usage.  Memory is cheap in the context I work in, so I might
be a bit biased...

>>One recent test showed 350MB of transient memory created by log4j to
log
>33
>>MB of data consisting of 33500 log entries; the number of transient
>objects
>>numbered in the millions and was uncountable by my tools.  The layout

Wow.  Huge numbers.  How did you measure transient memory, given that GC
was running?  What JVM was this, what GC parameters?

>>log4j.appender.R.layout.ConversionPattern=%d{MMM dd yyyy HH:mm:ss,SSS}
%t

Hmm.  I wonder if %d by itself would be better.

>>disregard for memory consumption disturbing.  I refactored it and I
can
>now
>>run the same test generating only 4 MB of transient data and 105000

RE: Proposed architecture changes to log4j for improved memory usage

I'm glad to see the feedback and interest on the message I posted.  I will
try to start responding to specific questions early next week.

For memory and object count I used JProbe 4.0.

I very much appreciate the functionality of Log4J.  I am sold on the API.
Any changes I am proposing I believe do not interfere with the current
usage of the API or current performance WRT response time(it might even
improve however slightly).  I believe 0 transient object usage is a worthy
goal and would not be difficult to fit into the existing framework.  The
main premise is this, move the formatting of the response out of a full in
memory representation(StringBuffer) and stream it in fragments to a
destination via a buffer(BufferedWriter).

On my project we have alot of GC.  The app does alot of logging, ~1 GB a
day and we are just starting to ramp up users.  Alot of the garbage is not
from logging.  The log4j changes I've made have really helped the system
overall because it is memory hungry to begin with.

Chris

RE: Proposed architecture changes to log4j for improved memory usage

Chris, your input is very helpful. 
 
You say that per day, you're logging ~1 GB. What is that, something like, 1.15 MB per second? Isn't that too much?
 
We did once have an issue with too much logging bringing performance down. To solve it, we added a feature in
our logging component where we can raise and lower logging levels on a per Logger basis on a running system.
This means we log almost nothing most of the time. We have to do this if we are tp support ~10,000 concurrent
users. If we think there's a problem, we can turn up a single Logger to debug level and get more information. 
 
-----Original Message----- 
From: Chris.Nokes <at> perficient.com [mailto:Chris.Nokes <at> perficient.com] 
Sent: Thu 10/3/2002 2:35 PM 
To: Log4J Developers List 
Cc: 
Subject: RE: Proposed architecture changes to log4j for improved memory usage




	I'm glad to see the feedback and interest on the message I posted.  I will
	try to start responding to specific questions early next week.
	
	For memory and object count I used JProbe 4.0.
	
	I very much appreciate the functionality of Log4J.  I am sold on the API.
	Any changes I am proposing I believe do not interfere with the current
	usage of the API or current performance WRT response time(it might even
	improve however slightly).  I believe 0 transient object usage is a worthy
	goal and would not be difficult to fit into the existing framework.  The
	main premise is this, move the formatting of the response out of a full in