On 07/09/10 10:10, Michael McMahon wrote:
Chris Hegarty wrote:
Michael,
CR 6967684: httpserver using a non thread-safe SimpleDateFormat
Bug description says it all. I guess in reality this may have gone
unseen for so long because, if two or more threads were servicing
requests the dates they would be generating should be fairly similar,
but worst case they could actually see partial of corrupt dates. This
bug causes random httpserver tests to fail when run with assertions
enabled.
The most reasonable solution is to use a thread-local instance of the
formatter, rather than creating one per request.
Webrev:
http://cr.openjdk.java.net/~chegar/6967684/webrev.00/webrev/
Thanks,
-Chris.
Interesting bug.
I wonder would it be better to use the ServerTimerTask to read the time
of day each time
it wakes up and the thread handlers would just read this value each time
they need it?
To clarify, the ServerTimerTask would provide the already formatted date
String, right?
That's probably what should have been done originally, as it scales
better with more traffic
and formatting dates is probably quite compute intensive.
A simple test shows 1,000,000 formats of new Date() takes 4407 millis, I
don't think this is too expensive.
If ServerTimerTask is to provide the date then we'll have to synchronize
its access. This may actually be more expensive for servers with many
many threads. It would be a highly contended monitor since every thread
will be required to hold it, albeit not for long.
Also, The default clock tick is 10 secs. This seems like a quite a large
value for caching the date timestamp.
-Chris.
- Michael.
