Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
5.4
-
None
Description
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
