commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: Logging: SimpleLog not thread-safe
Date Sat, 14 Oct 2006 12:07:01 GMT
Tomcat had this same issue a while back.  It was trying to use a single
SimpleDateFormat object to parse/format date-valued HTTP headers.  I
submitted the patch for it and I think we decided to just instantiate as
needed.  Local variables are garbage collected much more reliably from
what I understand.  And, as Simon pointed out, the probable disk i/o would
be the big bottleneck, not the object instantiation.

> You could just take a private copy of FastDateFormat from commons-lang
> which is thread-safe. Might bloat your jar-file size though.
> Stephen
>
> Simon Kitching wrote:
>> HI,
>>
>> On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote:
>>
>>>Yes, it'll be GC'ed when thread is. And initialized when first use in a
>>> new
>>>thread. Here is the test code:
>>
>>
>> But if an application has long-running threads then the object won't be
>> recycled until the thread dies. So an app with 100 threads has 100
>> SimpleDateFormat objects long-term.
>>
>> And as James noted, when using frameworks like Application Servers,
>> threads could be pooled in unexpected ways.
>>
>> I also suspect that in order to fetch data from a ThreadLocal, the JVM
>> effectively performs a get on a synchronised map, ie that ThreadLocal is
>> not much more efficient than having a synchronised static DateFormat on
>> SimpleLog (nb: I have no proof of this, just a hunch).
>>
>> I think the easiest & most reliable solution is to simply create a
>> SimpleDateFormat object in the method that needs it. Note that this is
>> only done after it has been determined that a message *will* be output,
>> which in most cases means that there will be disk io that will have far
>> more impact on the system than creating a simple object. Optimising the
>> path in commons-logging that determines *if* a message is to be logged
>> is important; optimising the actual logging operation is much less
>> critical.
>>
>> Of course I'm open to persuasion on this (eg performance stats)..
>>
>> Cheers,
>>
>> Simon
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


James Carman, President
Carman Consulting, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message