Hi All,
we are currently heavy load testing Tapestry 5.3.4-rc-7 in production
mode with Tomcat 6.0.35, so far it looks pretty good, but sometimes
(mostly) during a test series we
noticed unnecessary repeatly high number of assets requests with a http
status code "200" instead of the expected "304 Not Modified" code.
It took me a couple of hours to understand the problem, but I think I
found issue.
Looking at the request headers - the browser will send for example a
If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
for a previously received asset with headers like
Last-Modified Thu, 28 Jun 2012 22:32:41 GMT
Expires Sun, 26 Jun 2022 22:32:41 GMT
The header "If-Modified-Since " which will be parse by Tomcat's
FastHttpDateFormat.parseDate(..) method to a long, when called
ifModifiedSince = request.getDateHeader(IF_MODIFIED_SINCE_HEADER).
During this parsing any milliseconds are ignored/not available, but
Tapestry's ResourceChangeTrackerImpl service uses milliseconds:
/**
* Used in production mode as the last modified time of any resource
exposed to the client. Remember that
* all exposed assets include a URL with a version number, and each
new deployment of the application should change
* that version number.
*/
private final long fixedLastModifiedTime = System.currentTimeMillis();
Attribute fixedLastModifiedTime will be compared against a timestamp
without milliseconds in ResourceStreamerImpl (ifModifiedSince >=
lastModified)
if (ifModifiedSince > 0)
{
if (ifModifiedSince >= lastModified)
{
_response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
return;
}
}
which mostly doesn't work except in those cases were
System.currentTimeMillis returns a value ending with "000".
Basically what I mean is, that
System.out.println(new Date(1340920037999L));
System.out.println(new Date(1340920037000L));
Thu Jun 28 23:47:17 CEST 2012
Thu Jun 28 23:47:17 CEST 2012
produce the same string date, but the reverse will always be the long
1340920037000L.
For our load tests I have overwritten ResourceChangeTrackerImpl were we
initialize fixedLastModifiedTime like this
private final long fixedLastModifiedTime =
(System.currentTimeMillis()/1000L)*1000;
and then everything works as expected.
Is my assumption correct? Any chance to get this fixed for release 5.3.4?
Aloha
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
