I just checked in a fix for the "format" side (setting the "Last-Modified"
header). This one is much harder to hit, but that doesn't mean that you
can't. The "parse" side (getting the "If-Modified-Since" header) has been
fixed in the nightly for quite some time now.
----- Original Message -----
From: "Hugh J. L." <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, September 17, 2002 7:12 PM
Subject: Bug in DateTool in tomcat connector util?
> Hi,
>
> I found a bug (?) when i was testing tomcat3.3 using
> MS web stress tool. I set up large amount of
> concurrent requests for static files, each with header
> If-Modified-Since which is newer than actual
> last-modified-time of those requested files. I should
> have got 304 response for ALL requests in this case,
> however, i got many 304, a few 200, and even
> NumberFormatException occasionally. This didn't happen
> if i tested using only one client thread. I looked
> into java.text.SimpleDateFormat and suspected it was
> possibly a synchronization problem. Then I added
> synchronization control to DateTool.parse(String,
> DateFormat[]) as below and the problem was solved:
>
> synchronized(format[i]) {
> date = format[i].parse(dateString);
> }
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! News - Today's headlines
> http://news.yahoo.com
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
