The likely cause is that you are not setting an explicit application version number, so Tapestry supplies a random hex string.
http://zadachite-dev.appspot.com/assets/ctx/91328db67ddf7725/images/layout_v2/footer.jpg 91328db67ddf7725 is the application version number. Each instance of you app in the cluster is generating its own random version number, so a lot of times, the request simply isn't recognized if it isn't handled by the same instance that rendered the overall page. On Mon, Apr 12, 2010 at 9:23 PM, Alex Kotchnev <akoch...@gmail.com> wrote: > I spent some more time looking at this and I ended up removing the usage of > the ${asset:context:css/foobar.css} from the main templates. After doing so, > all of the issues related to the stylesheet (and the sub-stylesheets and > images that it loads) were cleared up - now, the stylesheets load properly > every time when they're not loaded through the asset service. > > I first thought that this might be an issue w/ how GAE handles static files > - supposedly, all files in the web context are handled specially ( w/ the > exception of JSPs of course, but that's not relevant in T5), probably served > up from outside of Jetty (which is what runs the app in GAE) and there might > be something that is weird in GAE giving access to those static assets. > However, after I switched to just using the raw path to the css (w/o using > the asset:context binding prefixes), I continued having the same > intermittent access issues for assets that are served from a component. > Which on its own indicates that the issue is somewhere between the Asset > service (which I haven't looked at the source code for yet) and the way it > uses the servlet API and/or the filesystem to serve the assets that it's > asked for. > > I haven't moved all my css / image serving out of the asset service - it has > some cool ideas in terms of being able to package the app. However, > considering that I'm dealing w/ a fairly simple app, and despite that I like > the ideas behind the asset service, I'll probably move off of it - I do > recall seeing some mentions of an alternative binding prefix to serve the > assets in question from a CDN ; however, considering that the google static > file serving infrastructure is probably as good as serving from a CDN, I'll > probably just stick to static files. > > Anyway, I thought this might be useful to someone else that might run into > issues with the Asset service and GAE. It would be interesting to look at > the asset service implementation and see if there is an issue to be filed w/ > GAE re: accessing resources (classpath and web context). > > Regards, > > Alex K > > On Mon, Apr 12, 2010 at 1:27 PM, akochnev_chub > <akoch...@commercehub.com>wrote: > >> >> I've been running into some issues w/ the asset service, in that at times >> it >> responds to service requests with 404s. After "warming up" the app by >> reloading the pages in question a few times, the asset service eventually >> responds w/ the assets. However, this results in a very unreliable >> rendering >> of the pages - at times (if the app happens to be "warm"), the pages >> render >> just fine; at other times, I have to reload them a few times before getting >> to proper rendering. Below are some more details on the issue, any >> suggestions on how to deal w/ it would be highly appreciated. >> >> >> There is a pretty good chance that this might be an issue w/ the underlying >> platform (GAE), and the way it chooses to swap the application in and out; >> however, if that were the case, I would have expected more of the requests >> to fail instead of the page content rendering fine and then the assets not >> returning in time. >> >> I think the issue is partially aggravated by the fact that I load the main >> stylesheet as a context asset (asset:context:/css/foo.css or something >> similar), instead of just using the "naked" (e.g. /css/foo.css w/o a >> context: prefix) path to the css in the layout; as a result, all of the >> "other" css (using yaml for layout) and the images referenced by the main >> css depend on the asset service (e.g. >> >> http://zadachite-dev.appspot.com/assets/ctx/91328db67ddf7725/images/layout_v2/footer.jpg >> ) >> instead of just being loaded as static files. I was thinking that switching >> the reference to the main stylesheet to not be a context: reference and >> marking the web app context resources as static (in the GAE web config >> file) >> might resolve the issue. >> >> So, here's an example : >> 1. go to http://zadachite-dev.appspot.com (this is the "dev" version which >> is unlikely to be warm right now) >> >> 2. Upon the initial loading of the pages, some of the graphics (more or >> less >> randomly) or stylesheets don't return as they get 404s: >> >> <html><head> >> <meta http-equiv="content-type" content="text/html;charset=utf-8"> >> <title>404 Unable to locate asset >> 'classpath:ctx/91328db67ddf7725/yaml/core/base.css' (the file does not >> exist).</title> >> </head> >> <body text=#000000 bgcolor=#ffffff> >> <h1>Error: Unable to locate asset >> 'classpath:ctx/91328db67ddf7725/yaml/core/base.css' (the file does not >> exist).</h1> >> </body></html> >> >> >> or for images, it's a straight 404 w/o any further response. >> >> 3. Browse to some of the other pages of the site - one by one, the >> "missing" >> assets start showing up one by one and eventually the layout renders >> correctly. After the app is "warmed up" now, even if you refresh the page >> including the initially cached assets, they load fine. >> -- >> View this message in context: >> http://old.nabble.com/Asset-service-issues-in-GAE-tp28219164p28219164.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
