tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Access Log /Filter/?
Date Wed, 03 Mar 2010 16:19:44 GMT
Hash: SHA1


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."

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
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message