Hello,
I think log.debug() method should first check current logging levels, or our
code will have those if() {} template everywhere.
I checked java.util.logging.Logger, and found this:
public void log(Level level, String msg, Object param1) {
if (level.intValue() < levelValue || levelValue == offValue) {
return;
}
LogRecord lr = new LogRecord(level, msg);
Object params[] = { param1 };
lr.setParameters(params);
doLog(lr);
}
Java 6 hotspot can determine that the StringBuffer synchronization isn't
actually used across threads in many cases, and thus it doesn't bother
synchronizing. Thus, the performance of the two classes becomes identical.
http://www.javalobby.org/java/forums/t88518.html
But it is more secure to not depend on specific jvm version, so it is more
appropriate to use StringBuilder when necessary.
On Wed, Mar 3, 2010 at 5:19 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jason,
>
> On 3/2/2010 7:21 PM, Jason Brittain wrote:
> >> Why does the request have to be an HTTP request in order to have the
> >> access log run?
> >
> > That does seem to be a bug.
>
> Note that this is not actually a part of the AccessLogValve, it's just
> part of Xie's implementation.
>
> > By default, the access logger logs the common
> > log web server
> > format, but of course it doesn't have to, so it should log non-HTTP
> requests
> > as well, but maybe
> > only if a non-default pattern is configured?
>
> Fair enough: most of the information you'd want to log is from HTTP
> requests (like the URI, for instance). The only things that are
> available for non-HTTP requests are:
>
> - - current date/time
> - - transaction time
> - - number of bytes read and sent
> - - local address
> - - remote address
> - - request attributes
> - - server name
>
> Actually, that's quite a bit, but I've never seen an HTTP log that
> doesn't log the URI :)
>
> >>> long t2 = System.currentTimeMillis();
> >>> long time = t2 - t1;
> >>
> >> This isn't your choice, it's in the original code, but why not just do:
> >>
> >> long elapsed = System.currentTimeMillis();
> >> ...
> >> elapsed = System.currentTimeMillis() - elapsed;
> >>
> >> ??
> >>
> >> Fewer items on the stack, etc.
> >>
> >
> > Except that then it is more difficult to debug. Right? It isn't as easy
> to
> > inspect the value of
> > the current time if you perform the subtraction without first assigning
> the
> > current time to a
> > variable.
>
> Fair enough, though debugging this timing code shouldn't really be
> required.
>
> >> > private Date getDate() {
> >>> // Only create a new Date once per second, max.
> >>> long systime = System.currentTimeMillis();
> >>> AccessDateStruct struct = currentDateStruct.get();
> >>> if ((systime - struct.currentDate.getTime()) > 1000) {
> >>> struct.currentDate.setTime(systime);
> >>> struct.currentDateString = null;
> >>> }
> >>> return struct.currentDate;
> >>> }
> >>
> >> I don't understand why this is ThreadLocal, instead of just synchronized
> >> across the object. Maybe it's slightly faster to avoid the
> >> synchronization and just use ThreadLocals, but I'm not sure how many
> >> requests per second a single Thread is going to process, so I'm not
> >> convinced that caching this data is worth the complexity it requires in
> >> this class. I'd love to hear from a Tomcat dev about this.
> >>
> >
> > Tomcat can (hopefully) answer a larger number of requests per second
> > every year on decently modern hardware. Benchmark it both ways on
> > a reasonably good/wide machine and you'll see why avoiding the sync
> > is helpful. I don't think it muddies the code very badly here.
>
> Okay. Certainly avoiding object creation is a good idea, and avoiding
> highly-contended synchronization is a good idea, too. I'd like to see a
> performance comparison between these strategies, though. Maybe I'll run
> one :)
>
> > The %b portion of the Combined Log Format is documented to be the "size
> of
> > the object returned to the client, not including the response headers."
> > http://httpd.apache.org/docs/1.3/logs.html#common
>
> Right. Presumably, the Content-Length is synonymous with the above, but
> it might not be. Also, Content-Length is not always set, so you'll get a
> lot of "-" written in the log even when response bodies actually has
> content. In this implementation, "%b" is equivalent to
> "%{Content-Length}o".
>
> Counting bytes isn't that big of a deal, either. I'll submit a patch at
> some point... maybe using a different pattern character.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuOjCAACgkQ9CaO5/Lv0PAAmgCgt9QVocFjXVNB3t4ib6fWOUIL
> ++YAoKdpBuT1uhobAIxasRsdw/PaK00e
> =zS1q
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
