tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magnus Kvalheim (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-2201) Serious issue with assets and checksums - different for same file
Date Tue, 05 Nov 2013 08:08:20 GMT

    [ https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813746#comment-13813746

Magnus Kvalheim commented on TAP5-2201:

Thanks, yes sounds like I've run into issues with global variables. Would explain the strange
issue with unpredictable mix of asset/asset.gz referensed assets in css. 

It is interesting that you say the /asset /asset.gz was originally conceived to support CDN.

CloudFront does support the 'Accept-Encoding' header and saves compressed and uncompressed
versions separately. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html
I've not done wide checking, but it's something basic I'd expect in any CDN that work with
origins. (I know Akamai supports)

As you indicate - there's one gotcha I've discovered. That is that CloudFront sends origin
requests in HTTP 1.0 format. 
Tapestry has a special handling in this case, TAP5-1880, which actually makes them incompatible
and effectively disable gzip. It would be good (at least for us), if it was possible to turn
off the special HTTP/1.0 short-circuit.

Thanks for taking time to investigate this.
Fyi, while this is in the works I'm going for a solution where gzip is disabled - and will
rely on F5(loadbalancer) to do the gzipping.

> Serious issue with assets and checksums - different for same file
> -----------------------------------------------------------------
>                 Key: TAP5-2201
>                 URL: https://issues.apache.org/jira/browse/TAP5-2201
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4
>            Reporter: Magnus Kvalheim
>              Labels: 5.4.22
>         Attachments: bootstrap.server2.css, bootstrap.server3.css, server2.png, server3.png
> Hi everybody.
> Today we've launched a website based on 5.4. We're very exited about the upcoming release(5.4)
and I'll post separately about our experiences (mostly great).
> Post release we've identified a potential serious issue related to assets and their checksums.
> What we see is that a handful of the assets generate different hashes for the same file.
> =Example: bootstrap.css=
> Server 1: 
> /asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 2:
> /asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 3:
> /asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> Server 3 - restart:
> /asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css
> We also see the same behaviour for the non gzip version of bootstrap.css.
> It is not only for /meta/
> =JCarouselWrapper.css=
> /asset/app/f59da774/mixins/ui/JCarouselWrapper.css
> /asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css
> As you can see - we're load balanced with app served from several nodes.
> Normally I'd serve these through CloudFront on a cookieless domain (with tapestry as
origin), but it's not possible as load balanced assets could hit 'wrong' server and get the
404 instead.
> So for now they are served through website domain with sticky sessions - and pray that
it don't cause us problems... :)
> All are served with same web container: 
> Apache Tomcat/7.0.39
> JDK 1.7.0_11

This message was sent by Atlassian JIRA

View raw message