You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Christian Zulehner <ch...@porscheinformatik.at> on 2011/06/17 13:00:25 UTC
Behaviour of StackAssetRequestHandler? (Performace)
Hi all,
seems that the StackAssetRequestHandler always sends back the Assetstack
instead of sending a 304 if not changed.
The class itself has no check for the last-modified timestamp, so the
timestamp is always recreated and thus a the asset is always send backt o
client, no matter if the underlying assets have changed or not.
So regarding performance and network traffic, this seems not quite the
optimal solution.
Found a small conversation here in this list about this issue (around 26
May 2010) , but no follow up or bug entry...
Is this behaviour intentional, if yes why? If not, can I open a Jira issue
for that?
best regards
Chris
Mit freundlichen Grüßen
Christian Zulehner
Im Auftrag der Porsche Informatik GmbH
Antwort: Re: Behaviour of StackAssetRequestHandler? (Performace)
Posted by Christian Zulehner <ch...@porscheinformatik.at>.
Hi,
thx Martin, my fault, didn't find this entry in Jira.. :-(
Your workaround seems to be ok for me too, thx a lot.
best regards
Christian Zulehner
Im Auftrag der Porsche Informatik GmbH
Von: "Martin Strand" <do...@gmail.com>
An: "Tapestry development" <de...@tapestry.apache.org>
Datum: 17.06.2011 17:41
Betreff: Re: Behaviour of StackAssetRequestHandler? (Performace)
On Fri, 17 Jun 2011 16:47:55 +0200, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 17 Jun 2011 08:00:25 -0300, Christian Zulehner
> <ch...@porscheinformatik.at> wrote:
>
>> Hi all,
>
> Hi!
>
>> seems that the StackAssetRequestHandler always sends back the
>> Assetstack
>> instead of sending a 304 if not changed.
>> The class itself has no check for the last-modified timestamp, so the
>> timestamp is always recreated and thus a the asset is always send backt
>> o
>> client, no matter if the underlying assets have changed or not.
>> So regarding performance and network traffic, this seems not quite the
>> optimal solution.
>> Found a small conversation here in this list about this issue (around
26
>> May 2010) , but no follow up or bug entry...
>> Is this behaviour intentional, if yes why? If not, can I open a Jira
>> issue for that?
>
> If confirmed, I think this deserves a JIRA issue.
This bug is already known:
https://issues.apache.org/jira/browse/TAP5-1119
Here's my cheap workaround. It's not a proper solution since it doesn't
actually check the underlying assets, but it seems to get the job done
//
// Quick workaround for this issue:
// https://issues.apache.org/jira/browse/TAP5-1119
//
// If any If-Modified-Since request header is present when requesting a
JavaScriptStack,
// a "304 Not modified" response is sent. There is no timestamp
comparison, but this
// ought to work fine anyway since asset URLs are supposed to change with
each new release.
//
public void contributeAssetDispatcher( //
MappedConfiguration<String, AssetRequestHandler>
configuration, //
@Autobuild final StackAssetRequestHandler
stackAssetRequestHandler)
{
configuration.override(RequestConstants.STACK_FOLDER, new
AssetRequestHandler()
{
@Override
public boolean handleAssetRequest(Request
request, Response response,
String extraPath)
throws IOException
{
if
(request.getHeader("If-Modified-Since") != null)
{
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
return
true;
}
return
stackAssetRequestHandler.handleAssetRequest(request, response,
extraPath);
}
});
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Behaviour of StackAssetRequestHandler? (Performace)
Posted by Martin Strand <do...@gmail.com>.
On Fri, 17 Jun 2011 16:47:55 +0200, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Fri, 17 Jun 2011 08:00:25 -0300, Christian Zulehner
> <ch...@porscheinformatik.at> wrote:
>
>> Hi all,
>
> Hi!
>
>> seems that the StackAssetRequestHandler always sends back the
>> Assetstack
>> instead of sending a 304 if not changed.
>> The class itself has no check for the last-modified timestamp, so the
>> timestamp is always recreated and thus a the asset is always send backt
>> o
>> client, no matter if the underlying assets have changed or not.
>> So regarding performance and network traffic, this seems not quite the
>> optimal solution.
>> Found a small conversation here in this list about this issue (around 26
>> May 2010) , but no follow up or bug entry...
>> Is this behaviour intentional, if yes why? If not, can I open a Jira
>> issue for that?
>
> If confirmed, I think this deserves a JIRA issue.
This bug is already known:
https://issues.apache.org/jira/browse/TAP5-1119
Here's my cheap workaround. It's not a proper solution since it doesn't
actually check the underlying assets, but it seems to get the job done
//
// Quick workaround for this issue:
// https://issues.apache.org/jira/browse/TAP5-1119
//
// If any If-Modified-Since request header is present when requesting a
JavaScriptStack,
// a "304 Not modified" response is sent. There is no timestamp
comparison, but this
// ought to work fine anyway since asset URLs are supposed to change with
each new release.
//
public void contributeAssetDispatcher( //
MappedConfiguration<String, AssetRequestHandler> configuration, //
@Autobuild final StackAssetRequestHandler stackAssetRequestHandler)
{
configuration.override(RequestConstants.STACK_FOLDER, new
AssetRequestHandler()
{
@Override
public boolean handleAssetRequest(Request request, Response response,
String extraPath)
throws IOException
{
if (request.getHeader("If-Modified-Since") != null)
{
response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
return true;
}
return stackAssetRequestHandler.handleAssetRequest(request, response,
extraPath);
}
});
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Behaviour of StackAssetRequestHandler? (Performace)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Fri, 17 Jun 2011 08:00:25 -0300, Christian Zulehner
<ch...@porscheinformatik.at> wrote:
> Hi all,
Hi!
> seems that the StackAssetRequestHandler always sends back the Assetstack
> instead of sending a 304 if not changed.
> The class itself has no check for the last-modified timestamp, so the
> timestamp is always recreated and thus a the asset is always send backt o
> client, no matter if the underlying assets have changed or not.
> So regarding performance and network traffic, this seems not quite the
> optimal solution.
> Found a small conversation here in this list about this issue (around 26
> May 2010) , but no follow up or bug entry...
> Is this behaviour intentional, if yes why? If not, can I open a Jira
> issue for that?
If confirmed, I think this deserves a JIRA issue.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org