You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Robert Lentz <ro...@teksolv.de> on 2012/06/29 00:38:52 UTC
Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with ResourceStreamerImpl/ResourceChangeTrackerImpl
and "If-Modified-Since" http header
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with
ResourceStreamerImpl/ResourceChangeTrackerImpl and "If-Modified-Since" http header
Posted by Howard Lewis Ship <hl...@gmail.com>.
https://issues.apache.org/jira/browse/TAP5-1964
On Thu, Jun 28, 2012 at 6:22 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Ah, reading back, I see exactly what Robert's getting at: the placeholder
> value, used in production, should be limited to one-second precision. This
> represents a change in 5.3 to ditch all the code that checks for changes:
> literally, the filter responsible is not instantiated in production mode,
> and several other services related to propagating events, become no-op
> placeholders.
>
>
> On Thu, Jun 28, 2012 at 6:20 PM, Howard Lewis Ship <hl...@gmail.com>wrote:
>
>> Robert is right on this one; there's code elsewhere to uses the
>> URLChangeTracker (the core of ResourceChangeTracker) at second (not
>> millisecond) precision, for this exact scenario ... I suspect something is
>> slightly out of wack for it to come back as it has.
>>
>>
>> On Thu, Jun 28, 2012 at 4:43 PM, Robert Lentz <ro...@teksolv.de> wrote:
>>
>>> Hi Thiago,
>>>
>>> well I don't have jetty available atm, but how would jetty or any other
>>> java date parser parse a string date including seconds but without
>>> milliseconds provided to a long milliseconds value
>>>
>>> If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
>>>
>>>
>>> I assume the millis range 000-999 must be ignored and the long will
>>> always ends with "000". Anything else is random - right?
>>>
>>> Aloha
>>> Robert
>>>
>>> Thiago H de Paula Figueiredo schrieb:
>>> > On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <ro...@teksolv.de>
>>> > wrote:
>>> >
>>> >> Hi All,
>>> >
>>> > Hi!
>>> >
>>> >> 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,
>>> >
>>> > Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can
>>> > fix in Tapestry's side and that wouldn't be the first time something
>>> > like that happens. Have you tried Jetty to test whether it happens in
>>> > it too?
>>> >
>>> > Your fix sounds harmless enough, so I see no reason for it to be
>>> > integrated in Tapestry itself.
>>> >
>>> > And thank you very much for noticing, investigating and provinding a
>>> > solution! :)
>>> >
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with
ResourceStreamerImpl/ResourceChangeTrackerImpl and "If-Modified-Since" http header
Posted by Howard Lewis Ship <hl...@gmail.com>.
Ah, reading back, I see exactly what Robert's getting at: the placeholder
value, used in production, should be limited to one-second precision. This
represents a change in 5.3 to ditch all the code that checks for changes:
literally, the filter responsible is not instantiated in production mode,
and several other services related to propagating events, become no-op
placeholders.
On Thu, Jun 28, 2012 at 6:20 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Robert is right on this one; there's code elsewhere to uses the
> URLChangeTracker (the core of ResourceChangeTracker) at second (not
> millisecond) precision, for this exact scenario ... I suspect something is
> slightly out of wack for it to come back as it has.
>
>
> On Thu, Jun 28, 2012 at 4:43 PM, Robert Lentz <ro...@teksolv.de> wrote:
>
>> Hi Thiago,
>>
>> well I don't have jetty available atm, but how would jetty or any other
>> java date parser parse a string date including seconds but without
>> milliseconds provided to a long milliseconds value
>>
>> If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
>>
>>
>> I assume the millis range 000-999 must be ignored and the long will
>> always ends with "000". Anything else is random - right?
>>
>> Aloha
>> Robert
>>
>> Thiago H de Paula Figueiredo schrieb:
>> > On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <ro...@teksolv.de>
>> > wrote:
>> >
>> >> Hi All,
>> >
>> > Hi!
>> >
>> >> 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,
>> >
>> > Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can
>> > fix in Tapestry's side and that wouldn't be the first time something
>> > like that happens. Have you tried Jetty to test whether it happens in
>> > it too?
>> >
>> > Your fix sounds harmless enough, so I see no reason for it to be
>> > integrated in Tapestry itself.
>> >
>> > And thank you very much for noticing, investigating and provinding a
>> > solution! :)
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with
ResourceStreamerImpl/ResourceChangeTrackerImpl and "If-Modified-Since" http header
Posted by Howard Lewis Ship <hl...@gmail.com>.
Robert is right on this one; there's code elsewhere to uses the
URLChangeTracker (the core of ResourceChangeTracker) at second (not
millisecond) precision, for this exact scenario ... I suspect something is
slightly out of wack for it to come back as it has.
On Thu, Jun 28, 2012 at 4:43 PM, Robert Lentz <ro...@teksolv.de> wrote:
> Hi Thiago,
>
> well I don't have jetty available atm, but how would jetty or any other
> java date parser parse a string date including seconds but without
> milliseconds provided to a long milliseconds value
>
> If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
>
>
> I assume the millis range 000-999 must be ignored and the long will
> always ends with "000". Anything else is random - right?
>
> Aloha
> Robert
>
> Thiago H de Paula Figueiredo schrieb:
> > On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <ro...@teksolv.de>
> > wrote:
> >
> >> Hi All,
> >
> > Hi!
> >
> >> 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,
> >
> > Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can
> > fix in Tapestry's side and that wouldn't be the first time something
> > like that happens. Have you tried Jetty to test whether it happens in
> > it too?
> >
> > Your fix sounds harmless enough, so I see no reason for it to be
> > integrated in Tapestry itself.
> >
> > And thank you very much for noticing, investigating and provinding a
> > solution! :)
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with
ResourceStreamerImpl/ResourceChangeTrackerImpl and "If-Modified-Since" http
header
Posted by Robert Lentz <ro...@teksolv.de>.
Hi Thiago,
well I don't have jetty available atm, but how would jetty or any other
java date parser parse a string date including seconds but without
milliseconds provided to a long milliseconds value
If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
I assume the millis range 000-999 must be ignored and the long will
always ends with "000". Anything else is random - right?
Aloha
Robert
Thiago H de Paula Figueiredo schrieb:
> On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <ro...@teksolv.de>
> wrote:
>
>> Hi All,
>
> Hi!
>
>> 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,
>
> Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can
> fix in Tapestry's side and that wouldn't be the first time something
> like that happens. Have you tried Jetty to test whether it happens in
> it too?
>
> Your fix sounds harmless enough, so I see no reason for it to be
> integrated in Tapestry itself.
>
> And thank you very much for noticing, investigating and provinding a
> solution! :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with
ResourceStreamerImpl/ResourceChangeTrackerImpl and "If-Modified-Since" http
header
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <ro...@teksolv.de> wrote:
> Hi All,
Hi!
> 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,
Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can fix
in Tapestry's side and that wouldn't be the first time something like that
happens. Have you tried Jetty to test whether it happens in it too?
Your fix sounds harmless enough, so I see no reason for it to be
integrated in Tapestry itself.
And thank you very much for noticing, investigating and provinding a
solution! :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org