You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by akochnev_chub <AK...@commercehub.com> on 2010/04/12 19:27:41 UTC
Asset service issues in GAE
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Asset service issues in GAE
Posted by Dmitry Gusev <dm...@gmail.com>.
On Wed, May 26, 2010 at 14:08, Alex Kotchnev <ak...@gmail.com> wrote:
> Dmitry,
> very nice analysis. Before explicitly setting the application version,
> did you observe the issues w/ the assets loading intermittently ?
>
>
Yes I had problems with this. Instead of returning CSS/JS contents T5
rendered index page and returned it as result.
> Regards,
>
> Alex K
>
> On Wed, May 26, 2010 at 5:55 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
>
> > I think have some progress in this.
> >
> > After upgrade to latest T5.2.0-SNAPSHOT resource links like
> >
> > <link rel="stylesheet" type="text/css"
> > > href="/assets/anjlab/cubics/css/cube.css" />
> > >
> >
> > not working anymore. So I desided to switch to Assets.
> >
> > Now the same CSS referenced like this:
> >
> > <link rel="stylesheet" type="text/css"
> > href="${asset:classpath:/anjlab/cubics/css/cube.css}" />
> >
> > Note its located in another jar. To make this work I had to contribute to
> > ClasspathAssetAliasManager:
> >
> > public static void
> > contributeClasspathAssetAliasManager(MappedConfiguration<String, String>
> > configuration)
> > {
> > configuration.add("cubics", "anjlab/cubics");
> > }
> >
> > Other stylesheets located at my app referenced like this:
> >
> > <link rel="stylesheet" type="text/css" href="${context:/css/all.css}"
> />
> >
> > During rendering this link became:
> >
> > http://ping-service.appspot.com/assets/1e85d3b227a83f96/ctx/css/all.css
> >
> > Note this '1e85d3b227a83f96' hash. As I learned this is
> > APPLICATION_VERSION,
> > which is by default:
> >
> > configuration.add(SymbolConstants.APPLICATION_VERSION,
> > Long.toHexString(random.nextLong()));
> >
> > So two different instances of applications will have different
> application
> > versions unless you contribute APPLICATION_VERSION in your AppModule
> (this
> > is what I had to do to avoid asset errors).
> >
> > Now imagine that GAE hosts two instances of your app to handle requests.
> > One
> > request retrieves HTML with links to CSS and JS files. Your browser will
> > try
> > load these assets simultaneously and it may happen that second instance
> > will
> > handle one of those requests, and since it have another value of
> > APPLICATION_VERSION you will get an error and browser couldn't load
> > response.
> >
> > To fix it you should declare APPLICATION_VERSION explicitly in AppModule,
> > here is mine:
> >
> > public static void contributeApplicationDefaults(
> > MappedConfiguration<String, String> configuration)
> > {
> > // ...
> > configuration.add(SymbolConstants.APPLICATION_VERSION, "beta");
> > }
> >
> >
> > Hope this help.
> >
> >
> >
> > On Tue, Apr 13, 2010 at 21:13, Dmitry Gusev <dm...@gmail.com>
> > wrote:
> >
> > > Alex,
> > >
> > > I don't have anything special in the app config, here is it:
> > >
> > > <?xml version="1.0" encoding="utf-8"?>
> > > <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
> > > <application>ping-service</application>
> > > <version>beta</version>
> > > <sessions-enabled>true</sessions-enabled>
> > > <precompilation-enabled>true</precompilation-enabled>
> > >
> > > <!-- Configure java.util.logging -->
> > > <system-properties>
> > > <property name="java.util.logging.config.file"
> > > value="WEB-INF/logging.properties"/>
> > > </system-properties>
> > >
> > > <admin-console>
> > > <page name="Appstats" url="/appstats/" />
> > > </admin-console>
> > > </appengine-web-app>
> > >
> > > I'd also recommend you to set up appstats, you may find something
> > > interesting in there.
> > >
> > > As for request deadlines, I'm also having HardDeadlineExceededError,
> and
> > > this usually happens in two reasons:
> > > 1. New T5 instance starting up. According to logs it tooks about 20
> > seconds
> > > in average to startup (thats why your may to be unresponsive within in
> 10
> > > seconds for ping service).
> > >
> > > Such requests in logs starts like this:
> > >
> > >
> > > 1.
> > >
> > > 0.1.0.2 - - [13/Apr/2010:06:38:31 -0700] "GET
> >
> /task/runjob;jsessionid=KpgsZ4bjrewWXHbiG4OlWg/?job=agxwaW5nLXNlcnZpY2VyGAsSCFNjaGVkdWxlGDwMCxIDSm9iGNEPDA
> > HTTP/1.1" 500 8799 "
> > http://ping-service.appspot.com/cron/?schedule=every%205%20minutes"
> > "AppEngine-Google; (+http://code.google.com/appengine)" "
> > ping-service.appspot.com"
> > >
> > > 2. D 04-13 06:38AM 10.523
> > >
> > > org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating
> service
> > 'TimingFilter'.
> > >
> > > 3. D 04-13 06:38AM 10.543
> > >
> > > org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating
> service
> > 'Utf8Filter'.
> > >
> > >
> > > ...
> > >
> > > 04-13 06:38AM 29.877
> > >
> > > dmitrygusev.ping.services.JobExecutor execute: Error fetching url
> > http://www.zadachite.com
> > > com.google.apphosting.api.DeadlineExceededException: This request
> > (94c02a0647915c1e) started at 2010/04/13 13:38:01.337 UTC and was still
> > executing at 2010/04/13 13:38:29.868 UTC.
> > >
> > >
> > > at java.lang.Object.wait(Native Method)
> > > at java.lang.Object.wait(Object.java:443)
> > > at java.util.concurrent.TimeUnit.timedWait(Unknown Source)
> > > at
> > com.google.apphosting.runtime.AsyncFuture.get(AsyncFuture.java:60)
> > >
> > >
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:319)
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:210)
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:131)
> > >
> > >
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:43)
> > > at
> > com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:104)
> > > at
> > com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:102)
> > >
> > >
> > > at java.security.AccessController.doPrivileged(Native Method)
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:102)
> > > at
> >
> com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:43)
> > >
> > >
> > > at
> >
> com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:225)
> > > at
> > com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:102)
> > > at
> >
> com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:34)
> > >
> > > was this yours? :)
> > >
> > > If you're using Spring, new T5 instance startup may take longer than 30
> > > secs which will lead to deadline exception. I used Spring for
> transaction
> > > management before, but I refused to use it and using Tynamo now.
> > >
> > > I also noticed that exceptions make take pretty much time of request,
> so
> > if
> > > you have any exceptions (no matter handled or not) requests become
> > longer. I
> > > found that if you're using Tynamo, you usually get one
> RollbackException
> > at
> > > the end of each request.
> > >
> > > 2. The other reason of deadline exceptions for me are long database
> > > requests. I found that in some cases datastore queries (even simple
> > queries)
> > > may take too many time to process sometime, but in other cases the same
> > > queries run pretty fast.
> > >
> > > p.s.
> > > favicon.ico is not an issue actually, all you need to fix it is put
> > > favicon.ico icon to your app.
> > > I already have favicon, but its with *.png extension. Looks like some
> > > browsers still looking for *.ico...
> > > I should convert that *.png to *.ico ... can't settle down to this :)
> > >
> > >
> > >
> > > On Tue, Apr 13, 2010 at 18:36, Alex Kotchnev <ak...@gmail.com>
> wrote:
> > >
> > >> Dmitry,
> > >> I do have the favicon.ico issue showing up in the logs as well, I'll
> > >> need
> > >> to look into that. Do you have anything special set up for the "static
> > >> files" section in the appengine config xml file ?
> > >>
> > >> The problem w/ the failed requests for assets is that they don't
> show
> > up
> > >> in the error log. Every once in a while, I'd get an error like this
> > (which
> > >> shouldn't happen - a request to a simple page should never take 30
> > >> seconds)
> > >> :
> > >>
> > >> Regards,
> > >>
> > >> Alex K
> > >>
> > >> Error for /faq
> > >> com.google.apphosting.runtime.HardDeadlineExceededError: This request
> > >> (b2c1ec272f017727) started at 2010/04/10 10:56:07.705 UTC and was
> > >> still executing at 2010/04/10 10:56:36.820 UTC.
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.access$008(CaseInsensitiveMap.java:30)
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$Position.put(CaseInsensitiveMap.java:287)
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:355)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:30)
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.internal.services.ClassPropertyAdapterImpl.<init>(ClassPropertyAdapterImpl.java:53)
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.buildAdapter(PropertyAccessImpl.java:92)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.getAdapter(PropertyAccessImpl.java:65)
> > >> at
> > >>
> $PropertyAccess_127e75ce676.getAdapter($PropertyAccess_127e75ce676.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyNode(PropertyConduitSourceImpl.java:978)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyOrMethod(PropertyConduitSourceImpl.java:971)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:433)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:416)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:270)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1254)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1121)
> > >>
> > >> at
> > >>
> >
> $PropertyConduitSource_127e75ce6ee.create($PropertyConduitSource_127e75ce6ee.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
> > >> at
> > >>
> $BindingFactory_127e75ce6ef.newBinding($BindingFactory_127e75ce6ef.java)
> > >>
> > >> at
> > >>
> $BindingFactory_127e75ce6e7.newBinding($BindingFactory_127e75ce6e7.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
> > >> at
> > >> $BindingSource_127e75ce6c5.newBinding($BindingSource_127e75ce6c5.java)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PageElementFactoryImpl.newExpansionElement(PageElementFactoryImpl.java:165)
> > >> at
> > >>
> >
> $PageElementFactory_127e75ce6df.newExpansionElement($PageElementFactory_127e75ce6df.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$15.execute(PageLoaderImpl.java:1024)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleEmbeddedComponent(ComponentAssemblerImpl.java:157)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$12.execute(PageLoaderImpl.java:947)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleRootComponent(ComponentAssemblerImpl.java:88)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:159)
> > >> at
> $PageLoader_127e75ce6d1.loadPage($PageLoader_127e75ce6d1.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
> > >> at $PagePool_127e75ce6d0.checkout($PagePool_127e75ce6d0.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
> > >>
> > >> at
> > >> $RequestPageCache_127e75ce6cf.get($RequestPageCache_127e75ce6cf.java)
> > >> at
> > >> $RequestPageCache_127e75ce6b8.get($RequestPageCache_127e75ce6b8.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:2262)
> > >> at
> > >>
> >
> $PageRenderRequestHandler_127e75ce6bb.handle($PageRenderRequestHandler_127e75ce6bb.java)
> > >> at
> > >>
> >
> $PageRenderRequestHandler_127e75ce6a3.handle($PageRenderRequestHandler_127e75ce6a3.java)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> > >> at
> > >>
> >
> $ComponentRequestHandler_127e75ce6a8.handlePageRender($ComponentRequestHandler_127e75ce6a8.java)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
> > >> at
> $Dispatcher_127e75ce6aa.dispatch($Dispatcher_127e75ce6aa.java)
> > >> at
> $Dispatcher_127e75ce6a0.dispatch($Dispatcher_127e75ce6a0.java)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper$1.doFilter(RequestFilterWrapper.java:60)
> > >>
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> > >> at
> > >>
> >
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> > >>
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper.service(RequestFilterWrapper.java:55)
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> > >>
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
> > >>
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
> > >>
> > >> at
> > >>
> >
> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
> > >> at
> > >>
> >
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
> > >> at
> > >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> > >>
> > >> at
> > >> $RequestHandler_127e75ce695.service($RequestHandler_127e75ce695.java)
> > >> at
> > >>
> >
> org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
> > >>
> > >> at
> > >>
> >
> org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
> > >> at
> > >>
> >
> org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
> > >>
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> > >> at
> > >>
> >
> $HttpServletRequestFilter_127e75ce693.service($HttpServletRequestFilter_127e75ce693.java)
> > >>
> > >> at
> > >>
> >
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
> > >>
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> > >> at
> > >>
> >
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> > >>
> > >> at
> > >>
> >
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> > >> at
> > >>
> >
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
> > >>
> > >> at nu.loca
> > >>
> > >>
> > >>
> > >> On Tue, Apr 13, 2010 at 9:31 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> > >> >wrote:
> > >>
> > >> > Hi, Alex
> > >> >
> > >> > I'm including *.css and *.png by simply using link rel, like this:
> > >> >
> > >> > <link rel="stylesheet" type="text/css"
> > >> > href="/assets/anjlab/cubics/css/cube.css" />
> > >> >
> > >> > cube.css located here:
> > >> >
> > >> >
> > >> >
> > >>
> >
> ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
> > >> >
> > >> > I also set up regexAuthorizer:
> > >> >
> > >> > public void contributeRegexAuthorizer(Configuration<String>
> regex)
> > >> > {
> > >> > String pathPattern =
> > >> > "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
> > >> > regex.add("^anjlab/cubics/css/" + pathPattern);
> > >> > regex.add("^anjlab/cubics/images/" + pathPattern);
> > >> > regex.add("^anjlab/cubics/js/" + pathPattern);
> > >> > regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
> > >> > }
> > >> >
> > >> > I can't say I have any problems with this.
> > >> > At least right now in my error list at GAE Admin console I don't
> have
> > >> any
> > >> > assets related issues.
> > >> >
> > >> > I have only one page actively using *.css, *.js, etc., here's the
> > >> > declarations:
> > >> >
> > >> > <head>
> > >> > <title>Job Analytics - Ping Service</title>
> > >> > <link rel="stylesheet" type="text/css" href="/css/all.css" />
> > >> > <link rel="icon" type="image/png" href="/favicon.png" />
> > >> > <link rel="stylesheet" type="text/css"
> > >> > href="/assets/anjlab/cubics/css/cube.css" />
> > >> > <link rel="stylesheet" type="text/css" href="/css/analytics.css"
> />
> > >> > <script type="text/javascript"
> > >> > src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
> > >> > <script type="text/javascript"
> > >> > src="/assets/anjlab/cubics/js/cube.js"></script>
> > >> > <!--[if IE]><script language="javascript" type="text/javascript"
> > >> > src="excanvas.min.js"></script><![endif]-->
> > >> > <script type="text/javascript" src="/js/jquery.flot.js"></script>
> > >> > <script type="text/javascript"
> > src="/js/jquery.flot.pie.js"></script>
> > >> > <script type="text/javascript" src="/js/analytics.js"></script>
> > >> > </head>
> > >> >
> > >> > p.s.
> > >> > One issue I have though is '/favicon.ico' problem :)
> > >> >
> > >> > On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com>
> > >> wrote:
> > >> >
> > >> > > Daniel,
> > >> > > I do try to watch out for T5/GAE related posts on this list and
> > try
> > >> to
> > >> > > respond to the best of my ability. I would blog about this more if
> I
> > >> > > weren't
> > >> > > as swamped with things to do.
> > >> > >
> > >> > > I would be interested in hearing from other folks (e.g. Dmitry)
> > that
> > >> > have
> > >> > > deployed on GAE - in previous questions relating to this issue,
> > folks
> > >> had
> > >> > > mentioned that they don't have a problem w/ this, which makes me
> > think
> > >> > that
> > >> > > I might have something configured incorrectly (although I'm not
> > doing
> > >> > > special here, other than having a few images loaded from the
> > >> > stylesheet).
> > >> > > I
> > >> > > do use the AssetAuthorizer (that was eventually added to 5.2) and
> > >> that's
> > >> > > another possible failure point (e.g. if for whatever reason, the
> > >> > > authorization fails in some cases and denies access).
> > >> > >
> > >> > > On the other hand, serving these assets as static content has
> > >> dropped
> > >> > my
> > >> > > CPU usage - I had an cron job watching the site and keeping it
> warm
> > >> (so
> > >> > > that
> > >> > > GAE doesn't swap it out), which was using up about 40% of the free
> > CPU
> > >> > > quota
> > >> > > - so far, the CPU usage should be about 20% lower.
> > >> > >
> > >> > > Regards,
> > >> > >
> > >> > > Alex Kotchnev
> > >> > >
> > >> > > On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <
> > dhenze@googlemail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Hi Alex,
> > >> > > >
> > >> > > > thanks for that follow-up post. Since I'm going to develop with
> T5
> > >> on
> > >> > GAE
> > >> > > > as well, this will be in the back of my head as a potential
> > cave-at.
> > >> > I'll
> > >> > > be
> > >> > > > interested in any further findings regarding GAE since it seems
> > that
> > >> > > > Tapestry is better tailored towards this particular platform
> > >> (compared
> > >> > to
> > >> > > > Wicket).
> > >> > > >
> > >> > > > Best regards
> > >> > > > Daniel
> > >> > > >
> > >> > > > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> > >> > > >
> > >> > > > 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<
> > >> > AKochnev@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-unsubscribe@tapestry.apache.org
> > >> > > >>> For additional commands, e-mail:
> users-help@tapestry.apache.org
> > >> > > >>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>
> > >> > > >>
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > >> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Dmitry Gusev
> > >> >
> > >> > AnjLab Team
> > >> > http://anjlab.com
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Dmitry Gusev
> > >
> > > AnjLab Team
> > > http://anjlab.com
> > >
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Asset service issues in GAE
Posted by Alex Kotchnev <ak...@gmail.com>.
Dmitry,
very nice analysis. Before explicitly setting the application version,
did you observe the issues w/ the assets loading intermittently ?
Regards,
Alex K
On Wed, May 26, 2010 at 5:55 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> I think have some progress in this.
>
> After upgrade to latest T5.2.0-SNAPSHOT resource links like
>
> <link rel="stylesheet" type="text/css"
> > href="/assets/anjlab/cubics/css/cube.css" />
> >
>
> not working anymore. So I desided to switch to Assets.
>
> Now the same CSS referenced like this:
>
> <link rel="stylesheet" type="text/css"
> href="${asset:classpath:/anjlab/cubics/css/cube.css}" />
>
> Note its located in another jar. To make this work I had to contribute to
> ClasspathAssetAliasManager:
>
> public static void
> contributeClasspathAssetAliasManager(MappedConfiguration<String, String>
> configuration)
> {
> configuration.add("cubics", "anjlab/cubics");
> }
>
> Other stylesheets located at my app referenced like this:
>
> <link rel="stylesheet" type="text/css" href="${context:/css/all.css}" />
>
> During rendering this link became:
>
> http://ping-service.appspot.com/assets/1e85d3b227a83f96/ctx/css/all.css
>
> Note this '1e85d3b227a83f96' hash. As I learned this is
> APPLICATION_VERSION,
> which is by default:
>
> configuration.add(SymbolConstants.APPLICATION_VERSION,
> Long.toHexString(random.nextLong()));
>
> So two different instances of applications will have different application
> versions unless you contribute APPLICATION_VERSION in your AppModule (this
> is what I had to do to avoid asset errors).
>
> Now imagine that GAE hosts two instances of your app to handle requests.
> One
> request retrieves HTML with links to CSS and JS files. Your browser will
> try
> load these assets simultaneously and it may happen that second instance
> will
> handle one of those requests, and since it have another value of
> APPLICATION_VERSION you will get an error and browser couldn't load
> response.
>
> To fix it you should declare APPLICATION_VERSION explicitly in AppModule,
> here is mine:
>
> public static void contributeApplicationDefaults(
> MappedConfiguration<String, String> configuration)
> {
> // ...
> configuration.add(SymbolConstants.APPLICATION_VERSION, "beta");
> }
>
>
> Hope this help.
>
>
>
> On Tue, Apr 13, 2010 at 21:13, Dmitry Gusev <dm...@gmail.com>
> wrote:
>
> > Alex,
> >
> > I don't have anything special in the app config, here is it:
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
> > <application>ping-service</application>
> > <version>beta</version>
> > <sessions-enabled>true</sessions-enabled>
> > <precompilation-enabled>true</precompilation-enabled>
> >
> > <!-- Configure java.util.logging -->
> > <system-properties>
> > <property name="java.util.logging.config.file"
> > value="WEB-INF/logging.properties"/>
> > </system-properties>
> >
> > <admin-console>
> > <page name="Appstats" url="/appstats/" />
> > </admin-console>
> > </appengine-web-app>
> >
> > I'd also recommend you to set up appstats, you may find something
> > interesting in there.
> >
> > As for request deadlines, I'm also having HardDeadlineExceededError, and
> > this usually happens in two reasons:
> > 1. New T5 instance starting up. According to logs it tooks about 20
> seconds
> > in average to startup (thats why your may to be unresponsive within in 10
> > seconds for ping service).
> >
> > Such requests in logs starts like this:
> >
> >
> > 1.
> >
> > 0.1.0.2 - - [13/Apr/2010:06:38:31 -0700] "GET
> /task/runjob;jsessionid=KpgsZ4bjrewWXHbiG4OlWg/?job=agxwaW5nLXNlcnZpY2VyGAsSCFNjaGVkdWxlGDwMCxIDSm9iGNEPDA
> HTTP/1.1" 500 8799 "
> http://ping-service.appspot.com/cron/?schedule=every%205%20minutes"
> "AppEngine-Google; (+http://code.google.com/appengine)" "
> ping-service.appspot.com"
> >
> > 2. D 04-13 06:38AM 10.523
> >
> > org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating service
> 'TimingFilter'.
> >
> > 3. D 04-13 06:38AM 10.543
> >
> > org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating service
> 'Utf8Filter'.
> >
> >
> > ...
> >
> > 04-13 06:38AM 29.877
> >
> > dmitrygusev.ping.services.JobExecutor execute: Error fetching url
> http://www.zadachite.com
> > com.google.apphosting.api.DeadlineExceededException: This request
> (94c02a0647915c1e) started at 2010/04/13 13:38:01.337 UTC and was still
> executing at 2010/04/13 13:38:29.868 UTC.
> >
> >
> > at java.lang.Object.wait(Native Method)
> > at java.lang.Object.wait(Object.java:443)
> > at java.util.concurrent.TimeUnit.timedWait(Unknown Source)
> > at
> com.google.apphosting.runtime.AsyncFuture.get(AsyncFuture.java:60)
> >
> >
> > at
> com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:319)
> > at
> com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:210)
> > at
> com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:131)
> >
> >
> > at
> com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:43)
> > at
> com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:104)
> > at
> com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:102)
> >
> >
> > at java.security.AccessController.doPrivileged(Native Method)
> > at
> com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:102)
> > at
> com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:43)
> >
> >
> > at
> com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:225)
> > at
> com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:102)
> > at
> com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:34)
> >
> > was this yours? :)
> >
> > If you're using Spring, new T5 instance startup may take longer than 30
> > secs which will lead to deadline exception. I used Spring for transaction
> > management before, but I refused to use it and using Tynamo now.
> >
> > I also noticed that exceptions make take pretty much time of request, so
> if
> > you have any exceptions (no matter handled or not) requests become
> longer. I
> > found that if you're using Tynamo, you usually get one RollbackException
> at
> > the end of each request.
> >
> > 2. The other reason of deadline exceptions for me are long database
> > requests. I found that in some cases datastore queries (even simple
> queries)
> > may take too many time to process sometime, but in other cases the same
> > queries run pretty fast.
> >
> > p.s.
> > favicon.ico is not an issue actually, all you need to fix it is put
> > favicon.ico icon to your app.
> > I already have favicon, but its with *.png extension. Looks like some
> > browsers still looking for *.ico...
> > I should convert that *.png to *.ico ... can't settle down to this :)
> >
> >
> >
> > On Tue, Apr 13, 2010 at 18:36, Alex Kotchnev <ak...@gmail.com> wrote:
> >
> >> Dmitry,
> >> I do have the favicon.ico issue showing up in the logs as well, I'll
> >> need
> >> to look into that. Do you have anything special set up for the "static
> >> files" section in the appengine config xml file ?
> >>
> >> The problem w/ the failed requests for assets is that they don't show
> up
> >> in the error log. Every once in a while, I'd get an error like this
> (which
> >> shouldn't happen - a request to a simple page should never take 30
> >> seconds)
> >> :
> >>
> >> Regards,
> >>
> >> Alex K
> >>
> >> Error for /faq
> >> com.google.apphosting.runtime.HardDeadlineExceededError: This request
> >> (b2c1ec272f017727) started at 2010/04/10 10:56:07.705 UTC and was
> >> still executing at 2010/04/10 10:56:36.820 UTC.
> >>
> >> at
> >>
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.access$008(CaseInsensitiveMap.java:30)
> >> at
> >>
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$Position.put(CaseInsensitiveMap.java:287)
> >> at
> >>
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:355)
> >>
> >> at
> >>
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:30)
> >> at
> >>
> org.apache.tapestry5.ioc.internal.services.ClassPropertyAdapterImpl.<init>(ClassPropertyAdapterImpl.java:53)
> >> at
> >>
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.buildAdapter(PropertyAccessImpl.java:92)
> >>
> >> at
> >>
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.getAdapter(PropertyAccessImpl.java:65)
> >> at
> >> $PropertyAccess_127e75ce676.getAdapter($PropertyAccess_127e75ce676.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyNode(PropertyConduitSourceImpl.java:978)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyOrMethod(PropertyConduitSourceImpl.java:971)
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:433)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:416)
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:270)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1254)
> >> at
> >>
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1121)
> >>
> >> at
> >>
> $PropertyConduitSource_127e75ce6ee.create($PropertyConduitSource_127e75ce6ee.java)
> >> at
> >>
> org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
> >> at
> >> $BindingFactory_127e75ce6ef.newBinding($BindingFactory_127e75ce6ef.java)
> >>
> >> at
> >> $BindingFactory_127e75ce6e7.newBinding($BindingFactory_127e75ce6e7.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
> >> at
> >> $BindingSource_127e75ce6c5.newBinding($BindingSource_127e75ce6c5.java)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PageElementFactoryImpl.newExpansionElement(PageElementFactoryImpl.java:165)
> >> at
> >>
> $PageElementFactory_127e75ce6df.newExpansionElement($PageElementFactory_127e75ce6df.java)
> >> at
> >>
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$15.execute(PageLoaderImpl.java:1024)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> >> at
> >>
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleEmbeddedComponent(ComponentAssemblerImpl.java:157)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$12.execute(PageLoaderImpl.java:947)
> >> at
> >>
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> >> at
> >>
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleRootComponent(ComponentAssemblerImpl.java:88)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:159)
> >> at $PageLoader_127e75ce6d1.loadPage($PageLoader_127e75ce6d1.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
> >> at $PagePool_127e75ce6d0.checkout($PagePool_127e75ce6d0.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
> >>
> >> at
> >> $RequestPageCache_127e75ce6cf.get($RequestPageCache_127e75ce6cf.java)
> >> at
> >> $RequestPageCache_127e75ce6b8.get($RequestPageCache_127e75ce6b8.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
> >>
> >> at
> >>
> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:2262)
> >> at
> >>
> $PageRenderRequestHandler_127e75ce6bb.handle($PageRenderRequestHandler_127e75ce6bb.java)
> >> at
> >>
> $PageRenderRequestHandler_127e75ce6a3.handle($PageRenderRequestHandler_127e75ce6a3.java)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> >> at
> >>
> $ComponentRequestHandler_127e75ce6a8.handlePageRender($ComponentRequestHandler_127e75ce6a8.java)
> >>
> >> at
> >>
> org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
> >> at $Dispatcher_127e75ce6aa.dispatch($Dispatcher_127e75ce6aa.java)
> >> at $Dispatcher_127e75ce6a0.dispatch($Dispatcher_127e75ce6a0.java)
> >>
> >> at
> >>
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper$1.doFilter(RequestFilterWrapper.java:60)
> >>
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> >> at
> >>
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> >>
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper.service(RequestFilterWrapper.java:55)
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
> >>
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >> at
> >>
> org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >>
> >> at
> >>
> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
> >>
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >> at
> >>
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
> >> at
> >>
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
> >>
> >> at
> >>
> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
> >> at
> >>
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
> >> at
> >> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> >>
> >> at
> >> $RequestHandler_127e75ce695.service($RequestHandler_127e75ce695.java)
> >> at
> >>
> org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
> >>
> >> at
> >>
> org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
> >> at
> >>
> org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
> >>
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> >> at
> >>
> $HttpServletRequestFilter_127e75ce693.service($HttpServletRequestFilter_127e75ce693.java)
> >>
> >> at
> >>
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
> >>
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> >> at
> >>
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
> >>
> >> at
> >>
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> >> at
> >>
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
> >>
> >> at nu.loca
> >>
> >>
> >>
> >> On Tue, Apr 13, 2010 at 9:31 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >> >wrote:
> >>
> >> > Hi, Alex
> >> >
> >> > I'm including *.css and *.png by simply using link rel, like this:
> >> >
> >> > <link rel="stylesheet" type="text/css"
> >> > href="/assets/anjlab/cubics/css/cube.css" />
> >> >
> >> > cube.css located here:
> >> >
> >> >
> >> >
> >>
> ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
> >> >
> >> > I also set up regexAuthorizer:
> >> >
> >> > public void contributeRegexAuthorizer(Configuration<String> regex)
> >> > {
> >> > String pathPattern =
> >> > "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
> >> > regex.add("^anjlab/cubics/css/" + pathPattern);
> >> > regex.add("^anjlab/cubics/images/" + pathPattern);
> >> > regex.add("^anjlab/cubics/js/" + pathPattern);
> >> > regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
> >> > }
> >> >
> >> > I can't say I have any problems with this.
> >> > At least right now in my error list at GAE Admin console I don't have
> >> any
> >> > assets related issues.
> >> >
> >> > I have only one page actively using *.css, *.js, etc., here's the
> >> > declarations:
> >> >
> >> > <head>
> >> > <title>Job Analytics - Ping Service</title>
> >> > <link rel="stylesheet" type="text/css" href="/css/all.css" />
> >> > <link rel="icon" type="image/png" href="/favicon.png" />
> >> > <link rel="stylesheet" type="text/css"
> >> > href="/assets/anjlab/cubics/css/cube.css" />
> >> > <link rel="stylesheet" type="text/css" href="/css/analytics.css" />
> >> > <script type="text/javascript"
> >> > src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
> >> > <script type="text/javascript"
> >> > src="/assets/anjlab/cubics/js/cube.js"></script>
> >> > <!--[if IE]><script language="javascript" type="text/javascript"
> >> > src="excanvas.min.js"></script><![endif]-->
> >> > <script type="text/javascript" src="/js/jquery.flot.js"></script>
> >> > <script type="text/javascript"
> src="/js/jquery.flot.pie.js"></script>
> >> > <script type="text/javascript" src="/js/analytics.js"></script>
> >> > </head>
> >> >
> >> > p.s.
> >> > One issue I have though is '/favicon.ico' problem :)
> >> >
> >> > On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com>
> >> wrote:
> >> >
> >> > > Daniel,
> >> > > I do try to watch out for T5/GAE related posts on this list and
> try
> >> to
> >> > > respond to the best of my ability. I would blog about this more if I
> >> > > weren't
> >> > > as swamped with things to do.
> >> > >
> >> > > I would be interested in hearing from other folks (e.g. Dmitry)
> that
> >> > have
> >> > > deployed on GAE - in previous questions relating to this issue,
> folks
> >> had
> >> > > mentioned that they don't have a problem w/ this, which makes me
> think
> >> > that
> >> > > I might have something configured incorrectly (although I'm not
> doing
> >> > > special here, other than having a few images loaded from the
> >> > stylesheet).
> >> > > I
> >> > > do use the AssetAuthorizer (that was eventually added to 5.2) and
> >> that's
> >> > > another possible failure point (e.g. if for whatever reason, the
> >> > > authorization fails in some cases and denies access).
> >> > >
> >> > > On the other hand, serving these assets as static content has
> >> dropped
> >> > my
> >> > > CPU usage - I had an cron job watching the site and keeping it warm
> >> (so
> >> > > that
> >> > > GAE doesn't swap it out), which was using up about 40% of the free
> CPU
> >> > > quota
> >> > > - so far, the CPU usage should be about 20% lower.
> >> > >
> >> > > Regards,
> >> > >
> >> > > Alex Kotchnev
> >> > >
> >> > > On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <
> dhenze@googlemail.com>
> >> > > wrote:
> >> > >
> >> > > > Hi Alex,
> >> > > >
> >> > > > thanks for that follow-up post. Since I'm going to develop with T5
> >> on
> >> > GAE
> >> > > > as well, this will be in the back of my head as a potential
> cave-at.
> >> > I'll
> >> > > be
> >> > > > interested in any further findings regarding GAE since it seems
> that
> >> > > > Tapestry is better tailored towards this particular platform
> >> (compared
> >> > to
> >> > > > Wicket).
> >> > > >
> >> > > > Best regards
> >> > > > Daniel
> >> > > >
> >> > > > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> >> > > >
> >> > > > 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<
> >> > AKochnev@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-unsubscribe@tapestry.apache.org
> >> > > >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >
> >> > > >
> >> ---------------------------------------------------------------------
> >> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> >> > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Dmitry Gusev
> >> >
> >> > AnjLab Team
> >> > http://anjlab.com
> >> >
> >>
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Asset service issues in GAE
Posted by Dmitry Gusev <dm...@gmail.com>.
I think have some progress in this.
After upgrade to latest T5.2.0-SNAPSHOT resource links like
<link rel="stylesheet" type="text/css"
> href="/assets/anjlab/cubics/css/cube.css" />
>
not working anymore. So I desided to switch to Assets.
Now the same CSS referenced like this:
<link rel="stylesheet" type="text/css"
href="${asset:classpath:/anjlab/cubics/css/cube.css}" />
Note its located in another jar. To make this work I had to contribute to
ClasspathAssetAliasManager:
public static void
contributeClasspathAssetAliasManager(MappedConfiguration<String, String>
configuration)
{
configuration.add("cubics", "anjlab/cubics");
}
Other stylesheets located at my app referenced like this:
<link rel="stylesheet" type="text/css" href="${context:/css/all.css}" />
During rendering this link became:
http://ping-service.appspot.com/assets/1e85d3b227a83f96/ctx/css/all.css
Note this '1e85d3b227a83f96' hash. As I learned this is APPLICATION_VERSION,
which is by default:
configuration.add(SymbolConstants.APPLICATION_VERSION,
Long.toHexString(random.nextLong()));
So two different instances of applications will have different application
versions unless you contribute APPLICATION_VERSION in your AppModule (this
is what I had to do to avoid asset errors).
Now imagine that GAE hosts two instances of your app to handle requests. One
request retrieves HTML with links to CSS and JS files. Your browser will try
load these assets simultaneously and it may happen that second instance will
handle one of those requests, and since it have another value of
APPLICATION_VERSION you will get an error and browser couldn't load
response.
To fix it you should declare APPLICATION_VERSION explicitly in AppModule,
here is mine:
public static void contributeApplicationDefaults(
MappedConfiguration<String, String> configuration)
{
// ...
configuration.add(SymbolConstants.APPLICATION_VERSION, "beta");
}
Hope this help.
On Tue, Apr 13, 2010 at 21:13, Dmitry Gusev <dm...@gmail.com> wrote:
> Alex,
>
> I don't have anything special in the app config, here is it:
>
> <?xml version="1.0" encoding="utf-8"?>
> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
> <application>ping-service</application>
> <version>beta</version>
> <sessions-enabled>true</sessions-enabled>
> <precompilation-enabled>true</precompilation-enabled>
>
> <!-- Configure java.util.logging -->
> <system-properties>
> <property name="java.util.logging.config.file"
> value="WEB-INF/logging.properties"/>
> </system-properties>
>
> <admin-console>
> <page name="Appstats" url="/appstats/" />
> </admin-console>
> </appengine-web-app>
>
> I'd also recommend you to set up appstats, you may find something
> interesting in there.
>
> As for request deadlines, I'm also having HardDeadlineExceededError, and
> this usually happens in two reasons:
> 1. New T5 instance starting up. According to logs it tooks about 20 seconds
> in average to startup (thats why your may to be unresponsive within in 10
> seconds for ping service).
>
> Such requests in logs starts like this:
>
>
> 1.
>
> 0.1.0.2 - - [13/Apr/2010:06:38:31 -0700] "GET /task/runjob;jsessionid=KpgsZ4bjrewWXHbiG4OlWg/?job=agxwaW5nLXNlcnZpY2VyGAsSCFNjaGVkdWxlGDwMCxIDSm9iGNEPDA HTTP/1.1" 500 8799 "http://ping-service.appspot.com/cron/?schedule=every%205%20minutes" "AppEngine-Google; (+http://code.google.com/appengine)" "ping-service.appspot.com"
>
> 2. D 04-13 06:38AM 10.523
>
> org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating service 'TimingFilter'.
>
> 3. D 04-13 06:38AM 10.543
>
> org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating service 'Utf8Filter'.
>
>
> ...
>
> 04-13 06:38AM 29.877
>
> dmitrygusev.ping.services.JobExecutor execute: Error fetching url http://www.zadachite.com
> com.google.apphosting.api.DeadlineExceededException: This request (94c02a0647915c1e) started at 2010/04/13 13:38:01.337 UTC and was still executing at 2010/04/13 13:38:29.868 UTC.
>
>
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:443)
> at java.util.concurrent.TimeUnit.timedWait(Unknown Source)
> at com.google.apphosting.runtime.AsyncFuture.get(AsyncFuture.java:60)
>
>
> at com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:319)
> at com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:210)
> at com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:131)
>
>
> at com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:43)
> at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:104)
> at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:102)
>
>
> at java.security.AccessController.doPrivileged(Native Method)
> at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:102)
> at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:43)
>
>
> at com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:225)
> at com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:102)
> at com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:34)
>
> was this yours? :)
>
> If you're using Spring, new T5 instance startup may take longer than 30
> secs which will lead to deadline exception. I used Spring for transaction
> management before, but I refused to use it and using Tynamo now.
>
> I also noticed that exceptions make take pretty much time of request, so if
> you have any exceptions (no matter handled or not) requests become longer. I
> found that if you're using Tynamo, you usually get one RollbackException at
> the end of each request.
>
> 2. The other reason of deadline exceptions for me are long database
> requests. I found that in some cases datastore queries (even simple queries)
> may take too many time to process sometime, but in other cases the same
> queries run pretty fast.
>
> p.s.
> favicon.ico is not an issue actually, all you need to fix it is put
> favicon.ico icon to your app.
> I already have favicon, but its with *.png extension. Looks like some
> browsers still looking for *.ico...
> I should convert that *.png to *.ico ... can't settle down to this :)
>
>
>
> On Tue, Apr 13, 2010 at 18:36, Alex Kotchnev <ak...@gmail.com> wrote:
>
>> Dmitry,
>> I do have the favicon.ico issue showing up in the logs as well, I'll
>> need
>> to look into that. Do you have anything special set up for the "static
>> files" section in the appengine config xml file ?
>>
>> The problem w/ the failed requests for assets is that they don't show up
>> in the error log. Every once in a while, I'd get an error like this (which
>> shouldn't happen - a request to a simple page should never take 30
>> seconds)
>> :
>>
>> Regards,
>>
>> Alex K
>>
>> Error for /faq
>> com.google.apphosting.runtime.HardDeadlineExceededError: This request
>> (b2c1ec272f017727) started at 2010/04/10 10:56:07.705 UTC and was
>> still executing at 2010/04/10 10:56:36.820 UTC.
>>
>> at
>> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.access$008(CaseInsensitiveMap.java:30)
>> at
>> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$Position.put(CaseInsensitiveMap.java:287)
>> at
>> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:355)
>>
>> at
>> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:30)
>> at
>> org.apache.tapestry5.ioc.internal.services.ClassPropertyAdapterImpl.<init>(ClassPropertyAdapterImpl.java:53)
>> at
>> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.buildAdapter(PropertyAccessImpl.java:92)
>>
>> at
>> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.getAdapter(PropertyAccessImpl.java:65)
>> at
>> $PropertyAccess_127e75ce676.getAdapter($PropertyAccess_127e75ce676.java)
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyNode(PropertyConduitSourceImpl.java:978)
>>
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyOrMethod(PropertyConduitSourceImpl.java:971)
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:433)
>>
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:416)
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:270)
>>
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1254)
>> at
>> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1121)
>>
>> at
>> $PropertyConduitSource_127e75ce6ee.create($PropertyConduitSource_127e75ce6ee.java)
>> at
>> org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
>> at
>> $BindingFactory_127e75ce6ef.newBinding($BindingFactory_127e75ce6ef.java)
>>
>> at
>> $BindingFactory_127e75ce6e7.newBinding($BindingFactory_127e75ce6e7.java)
>> at
>> org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
>> at
>> $BindingSource_127e75ce6c5.newBinding($BindingSource_127e75ce6c5.java)
>>
>> at
>> org.apache.tapestry5.internal.services.PageElementFactoryImpl.newExpansionElement(PageElementFactoryImpl.java:165)
>> at
>> $PageElementFactory_127e75ce6df.newExpansionElement($PageElementFactory_127e75ce6df.java)
>> at
>> org.apache.tapestry5.internal.pageload.PageLoaderImpl$15.execute(PageLoaderImpl.java:1024)
>>
>> at
>> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
>> at
>> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleEmbeddedComponent(ComponentAssemblerImpl.java:157)
>>
>> at
>> org.apache.tapestry5.internal.pageload.PageLoaderImpl$12.execute(PageLoaderImpl.java:947)
>> at
>> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
>> at
>> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleRootComponent(ComponentAssemblerImpl.java:88)
>>
>> at
>> org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:159)
>> at $PageLoader_127e75ce6d1.loadPage($PageLoader_127e75ce6d1.java)
>> at
>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
>>
>> at
>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
>> at $PagePool_127e75ce6d0.checkout($PagePool_127e75ce6d0.java)
>> at
>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
>>
>> at
>> $RequestPageCache_127e75ce6cf.get($RequestPageCache_127e75ce6cf.java)
>> at
>> $RequestPageCache_127e75ce6b8.get($RequestPageCache_127e75ce6b8.java)
>> at
>> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
>>
>> at
>> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:2262)
>> at
>> $PageRenderRequestHandler_127e75ce6bb.handle($PageRenderRequestHandler_127e75ce6bb.java)
>> at
>> $PageRenderRequestHandler_127e75ce6a3.handle($PageRenderRequestHandler_127e75ce6a3.java)
>>
>> at
>> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
>> at
>> $ComponentRequestHandler_127e75ce6a8.handlePageRender($ComponentRequestHandler_127e75ce6a8.java)
>>
>> at
>> org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
>> at $Dispatcher_127e75ce6aa.dispatch($Dispatcher_127e75ce6aa.java)
>> at $Dispatcher_127e75ce6a0.dispatch($Dispatcher_127e75ce6a0.java)
>>
>> at
>> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper$1.doFilter(RequestFilterWrapper.java:60)
>>
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
>> at
>> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
>>
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper.service(RequestFilterWrapper.java:55)
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>> at
>> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
>>
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>> at
>> org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>>
>> at
>> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>> at
>> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
>>
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>> at
>> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
>> at
>> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
>>
>> at
>> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
>> at
>> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
>> at
>> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>>
>> at
>> $RequestHandler_127e75ce695.service($RequestHandler_127e75ce695.java)
>> at
>> org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
>>
>> at
>> org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
>> at
>> org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
>>
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
>> at
>> $HttpServletRequestFilter_127e75ce693.service($HttpServletRequestFilter_127e75ce693.java)
>>
>> at
>> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
>>
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
>> at
>> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
>>
>> at
>> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
>> at
>> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
>>
>> at nu.loca
>>
>>
>>
>> On Tue, Apr 13, 2010 at 9:31 AM, Dmitry Gusev <dmitry.gusev@gmail.com
>> >wrote:
>>
>> > Hi, Alex
>> >
>> > I'm including *.css and *.png by simply using link rel, like this:
>> >
>> > <link rel="stylesheet" type="text/css"
>> > href="/assets/anjlab/cubics/css/cube.css" />
>> >
>> > cube.css located here:
>> >
>> >
>> >
>> ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
>> >
>> > I also set up regexAuthorizer:
>> >
>> > public void contributeRegexAuthorizer(Configuration<String> regex)
>> > {
>> > String pathPattern =
>> > "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
>> > regex.add("^anjlab/cubics/css/" + pathPattern);
>> > regex.add("^anjlab/cubics/images/" + pathPattern);
>> > regex.add("^anjlab/cubics/js/" + pathPattern);
>> > regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
>> > }
>> >
>> > I can't say I have any problems with this.
>> > At least right now in my error list at GAE Admin console I don't have
>> any
>> > assets related issues.
>> >
>> > I have only one page actively using *.css, *.js, etc., here's the
>> > declarations:
>> >
>> > <head>
>> > <title>Job Analytics - Ping Service</title>
>> > <link rel="stylesheet" type="text/css" href="/css/all.css" />
>> > <link rel="icon" type="image/png" href="/favicon.png" />
>> > <link rel="stylesheet" type="text/css"
>> > href="/assets/anjlab/cubics/css/cube.css" />
>> > <link rel="stylesheet" type="text/css" href="/css/analytics.css" />
>> > <script type="text/javascript"
>> > src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
>> > <script type="text/javascript"
>> > src="/assets/anjlab/cubics/js/cube.js"></script>
>> > <!--[if IE]><script language="javascript" type="text/javascript"
>> > src="excanvas.min.js"></script><![endif]-->
>> > <script type="text/javascript" src="/js/jquery.flot.js"></script>
>> > <script type="text/javascript" src="/js/jquery.flot.pie.js"></script>
>> > <script type="text/javascript" src="/js/analytics.js"></script>
>> > </head>
>> >
>> > p.s.
>> > One issue I have though is '/favicon.ico' problem :)
>> >
>> > On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com>
>> wrote:
>> >
>> > > Daniel,
>> > > I do try to watch out for T5/GAE related posts on this list and try
>> to
>> > > respond to the best of my ability. I would blog about this more if I
>> > > weren't
>> > > as swamped with things to do.
>> > >
>> > > I would be interested in hearing from other folks (e.g. Dmitry) that
>> > have
>> > > deployed on GAE - in previous questions relating to this issue, folks
>> had
>> > > mentioned that they don't have a problem w/ this, which makes me think
>> > that
>> > > I might have something configured incorrectly (although I'm not doing
>> > > special here, other than having a few images loaded from the
>> > stylesheet).
>> > > I
>> > > do use the AssetAuthorizer (that was eventually added to 5.2) and
>> that's
>> > > another possible failure point (e.g. if for whatever reason, the
>> > > authorization fails in some cases and denies access).
>> > >
>> > > On the other hand, serving these assets as static content has
>> dropped
>> > my
>> > > CPU usage - I had an cron job watching the site and keeping it warm
>> (so
>> > > that
>> > > GAE doesn't swap it out), which was using up about 40% of the free CPU
>> > > quota
>> > > - so far, the CPU usage should be about 20% lower.
>> > >
>> > > Regards,
>> > >
>> > > Alex Kotchnev
>> > >
>> > > On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dh...@googlemail.com>
>> > > wrote:
>> > >
>> > > > Hi Alex,
>> > > >
>> > > > thanks for that follow-up post. Since I'm going to develop with T5
>> on
>> > GAE
>> > > > as well, this will be in the back of my head as a potential cave-at.
>> > I'll
>> > > be
>> > > > interested in any further findings regarding GAE since it seems that
>> > > > Tapestry is better tailored towards this particular platform
>> (compared
>> > to
>> > > > Wicket).
>> > > >
>> > > > Best regards
>> > > > Daniel
>> > > >
>> > > > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
>> > > >
>> > > > 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<
>> > AKochnev@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-unsubscribe@tapestry.apache.org
>> > > >>> For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Dmitry Gusev
>> >
>> > AnjLab Team
>> > http://anjlab.com
>> >
>>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Asset service issues in GAE
Posted by Dmitry Gusev <dm...@gmail.com>.
Alex,
I don't have anything special in the app config, here is it:
<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>ping-service</application>
<version>beta</version>
<sessions-enabled>true</sessions-enabled>
<precompilation-enabled>true</precompilation-enabled>
<!-- Configure java.util.logging -->
<system-properties>
<property name="java.util.logging.config.file"
value="WEB-INF/logging.properties"/>
</system-properties>
<admin-console>
<page name="Appstats" url="/appstats/" />
</admin-console>
</appengine-web-app>
I'd also recommend you to set up appstats, you may find something
interesting in there.
As for request deadlines, I'm also having HardDeadlineExceededError, and
this usually happens in two reasons:
1. New T5 instance starting up. According to logs it tooks about 20 seconds
in average to startup (thats why your may to be unresponsive within in 10
seconds for ping service).
Such requests in logs starts like this:
1.
0.1.0.2 - - [13/Apr/2010:06:38:31 -0700] "GET
/task/runjob;jsessionid=KpgsZ4bjrewWXHbiG4OlWg/?job=agxwaW5nLXNlcnZpY2VyGAsSCFNjaGVkdWxlGDwMCxIDSm9iGNEPDA
HTTP/1.1" 500 8799
"http://ping-service.appspot.com/cron/?schedule=every%205%20minutes"
"AppEngine-Google; (+http://code.google.com/appengine)"
"ping-service.appspot.com"
2. D 04-13 06:38AM 10.523
org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating
service 'TimingFilter'.
3. D 04-13 06:38AM 10.543
org.apache.tapestry5.ioc.internal.ModuleImpl create: Creating
service 'Utf8Filter'.
...
04-13 06:38AM 29.877
dmitrygusev.ping.services.JobExecutor execute: Error fetching url
http://www.zadachite.com
com.google.apphosting.api.DeadlineExceededException: This request
(94c02a0647915c1e) started at 2010/04/13 13:38:01.337 UTC and was
still executing at 2010/04/13 13:38:29.868 UTC.
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:443)
at java.util.concurrent.TimeUnit.timedWait(Unknown Source)
at com.google.apphosting.runtime.AsyncFuture.get(AsyncFuture.java:60)
at com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:319)
at com.google.apphosting.runtime.ApiProxyImpl$AsyncApiFuture.get(ApiProxyImpl.java:210)
at com.google.apphosting.runtime.ApiProxyImpl.doSyncCall(ApiProxyImpl.java:131)
at com.google.apphosting.runtime.ApiProxyImpl.access$000(ApiProxyImpl.java:43)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:104)
at com.google.apphosting.runtime.ApiProxyImpl$1.run(ApiProxyImpl.java:102)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:102)
at com.google.apphosting.runtime.ApiProxyImpl.makeSyncCall(ApiProxyImpl.java:43)
at com.google.appengine.tools.appstats.Recorder.makeSyncCall(Recorder.java:225)
at com.google.apphosting.api.ApiProxy.makeSyncCall(ApiProxy.java:102)
at com.google.appengine.api.urlfetch.URLFetchServiceImpl.fetch(URLFetchServiceImpl.java:34)
was this yours? :)
If you're using Spring, new T5 instance startup may take longer than 30 secs
which will lead to deadline exception. I used Spring for transaction
management before, but I refused to use it and using Tynamo now.
I also noticed that exceptions make take pretty much time of request, so if
you have any exceptions (no matter handled or not) requests become longer. I
found that if you're using Tynamo, you usually get one RollbackException at
the end of each request.
2. The other reason of deadline exceptions for me are long database
requests. I found that in some cases datastore queries (even simple queries)
may take too many time to process sometime, but in other cases the same
queries run pretty fast.
p.s.
favicon.ico is not an issue actually, all you need to fix it is put
favicon.ico icon to your app.
I already have favicon, but its with *.png extension. Looks like some
browsers still looking for *.ico...
I should convert that *.png to *.ico ... can't settle down to this :)
On Tue, Apr 13, 2010 at 18:36, Alex Kotchnev <ak...@gmail.com> wrote:
> Dmitry,
> I do have the favicon.ico issue showing up in the logs as well, I'll need
> to look into that. Do you have anything special set up for the "static
> files" section in the appengine config xml file ?
>
> The problem w/ the failed requests for assets is that they don't show up
> in the error log. Every once in a while, I'd get an error like this (which
> shouldn't happen - a request to a simple page should never take 30 seconds)
> :
>
> Regards,
>
> Alex K
>
> Error for /faq
> com.google.apphosting.runtime.HardDeadlineExceededError: This request
> (b2c1ec272f017727) started at 2010/04/10 10:56:07.705 UTC and was
> still executing at 2010/04/10 10:56:36.820 UTC.
>
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.access$008(CaseInsensitiveMap.java:30)
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap$Position.put(CaseInsensitiveMap.java:287)
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:355)
>
> at
> org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:30)
> at
> org.apache.tapestry5.ioc.internal.services.ClassPropertyAdapterImpl.<init>(ClassPropertyAdapterImpl.java:53)
> at
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.buildAdapter(PropertyAccessImpl.java:92)
>
> at
> org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.getAdapter(PropertyAccessImpl.java:65)
> at
> $PropertyAccess_127e75ce676.getAdapter($PropertyAccess_127e75ce676.java)
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyNode(PropertyConduitSourceImpl.java:978)
>
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyOrMethod(PropertyConduitSourceImpl.java:971)
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:433)
>
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:416)
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:270)
>
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1254)
> at
> org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1121)
>
> at
> $PropertyConduitSource_127e75ce6ee.create($PropertyConduitSource_127e75ce6ee.java)
> at
> org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
> at
> $BindingFactory_127e75ce6ef.newBinding($BindingFactory_127e75ce6ef.java)
>
> at
> $BindingFactory_127e75ce6e7.newBinding($BindingFactory_127e75ce6e7.java)
> at
> org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
> at
> $BindingSource_127e75ce6c5.newBinding($BindingSource_127e75ce6c5.java)
>
> at
> org.apache.tapestry5.internal.services.PageElementFactoryImpl.newExpansionElement(PageElementFactoryImpl.java:165)
> at
> $PageElementFactory_127e75ce6df.newExpansionElement($PageElementFactory_127e75ce6df.java)
> at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$15.execute(PageLoaderImpl.java:1024)
>
> at
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> at
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleEmbeddedComponent(ComponentAssemblerImpl.java:157)
>
> at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl$12.execute(PageLoaderImpl.java:947)
> at
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
> at
> org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleRootComponent(ComponentAssemblerImpl.java:88)
>
> at
> org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:159)
> at $PageLoader_127e75ce6d1.loadPage($PageLoader_127e75ce6d1.java)
> at
> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
>
> at
> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
> at $PagePool_127e75ce6d0.checkout($PagePool_127e75ce6d0.java)
> at
> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
>
> at
> $RequestPageCache_127e75ce6cf.get($RequestPageCache_127e75ce6cf.java)
> at
> $RequestPageCache_127e75ce6b8.get($RequestPageCache_127e75ce6b8.java)
> at
> org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
>
> at
> org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:2262)
> at
> $PageRenderRequestHandler_127e75ce6bb.handle($PageRenderRequestHandler_127e75ce6bb.java)
> at
> $PageRenderRequestHandler_127e75ce6a3.handle($PageRenderRequestHandler_127e75ce6a3.java)
>
> at
> org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
> at
> $ComponentRequestHandler_127e75ce6a8.handlePageRender($ComponentRequestHandler_127e75ce6a8.java)
>
> at
> org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
> at $Dispatcher_127e75ce6aa.dispatch($Dispatcher_127e75ce6aa.java)
> at $Dispatcher_127e75ce6a0.dispatch($Dispatcher_127e75ce6a0.java)
>
> at
> org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
> at
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper$1.doFilter(RequestFilterWrapper.java:60)
>
> at
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> at
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
>
> at
> nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper.service(RequestFilterWrapper.java:55)
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> at
> org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
>
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> at
> org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>
> at
> org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> at
> org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
>
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
> at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
> at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
>
> at
> org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
> at
> org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
> at
> $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
>
> at
> $RequestHandler_127e75ce695.service($RequestHandler_127e75ce695.java)
> at
> org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
> at
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
>
> at
> org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
> at
> org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
>
> at
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> at
> $HttpServletRequestFilter_127e75ce693.service($HttpServletRequestFilter_127e75ce693.java)
>
> at
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
> at
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
>
> at
> nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
> at
> org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
>
> at
> nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
> at
> $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
>
> at nu.loca
>
>
>
> On Tue, Apr 13, 2010 at 9:31 AM, Dmitry Gusev <dmitry.gusev@gmail.com
> >wrote:
>
> > Hi, Alex
> >
> > I'm including *.css and *.png by simply using link rel, like this:
> >
> > <link rel="stylesheet" type="text/css"
> > href="/assets/anjlab/cubics/css/cube.css" />
> >
> > cube.css located here:
> >
> >
> >
> ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
> >
> > I also set up regexAuthorizer:
> >
> > public void contributeRegexAuthorizer(Configuration<String> regex)
> > {
> > String pathPattern =
> > "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
> > regex.add("^anjlab/cubics/css/" + pathPattern);
> > regex.add("^anjlab/cubics/images/" + pathPattern);
> > regex.add("^anjlab/cubics/js/" + pathPattern);
> > regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
> > }
> >
> > I can't say I have any problems with this.
> > At least right now in my error list at GAE Admin console I don't have any
> > assets related issues.
> >
> > I have only one page actively using *.css, *.js, etc., here's the
> > declarations:
> >
> > <head>
> > <title>Job Analytics - Ping Service</title>
> > <link rel="stylesheet" type="text/css" href="/css/all.css" />
> > <link rel="icon" type="image/png" href="/favicon.png" />
> > <link rel="stylesheet" type="text/css"
> > href="/assets/anjlab/cubics/css/cube.css" />
> > <link rel="stylesheet" type="text/css" href="/css/analytics.css" />
> > <script type="text/javascript"
> > src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
> > <script type="text/javascript"
> > src="/assets/anjlab/cubics/js/cube.js"></script>
> > <!--[if IE]><script language="javascript" type="text/javascript"
> > src="excanvas.min.js"></script><![endif]-->
> > <script type="text/javascript" src="/js/jquery.flot.js"></script>
> > <script type="text/javascript" src="/js/jquery.flot.pie.js"></script>
> > <script type="text/javascript" src="/js/analytics.js"></script>
> > </head>
> >
> > p.s.
> > One issue I have though is '/favicon.ico' problem :)
> >
> > On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com> wrote:
> >
> > > Daniel,
> > > I do try to watch out for T5/GAE related posts on this list and try
> to
> > > respond to the best of my ability. I would blog about this more if I
> > > weren't
> > > as swamped with things to do.
> > >
> > > I would be interested in hearing from other folks (e.g. Dmitry) that
> > have
> > > deployed on GAE - in previous questions relating to this issue, folks
> had
> > > mentioned that they don't have a problem w/ this, which makes me think
> > that
> > > I might have something configured incorrectly (although I'm not doing
> > > special here, other than having a few images loaded from the
> > stylesheet).
> > > I
> > > do use the AssetAuthorizer (that was eventually added to 5.2) and
> that's
> > > another possible failure point (e.g. if for whatever reason, the
> > > authorization fails in some cases and denies access).
> > >
> > > On the other hand, serving these assets as static content has dropped
> > my
> > > CPU usage - I had an cron job watching the site and keeping it warm (so
> > > that
> > > GAE doesn't swap it out), which was using up about 40% of the free CPU
> > > quota
> > > - so far, the CPU usage should be about 20% lower.
> > >
> > > Regards,
> > >
> > > Alex Kotchnev
> > >
> > > On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dh...@googlemail.com>
> > > wrote:
> > >
> > > > Hi Alex,
> > > >
> > > > thanks for that follow-up post. Since I'm going to develop with T5 on
> > GAE
> > > > as well, this will be in the back of my head as a potential cave-at.
> > I'll
> > > be
> > > > interested in any further findings regarding GAE since it seems that
> > > > Tapestry is better tailored towards this particular platform
> (compared
> > to
> > > > Wicket).
> > > >
> > > > Best regards
> > > > Daniel
> > > >
> > > > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> > > >
> > > > 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<
> > AKochnev@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-unsubscribe@tapestry.apache.org
> > > >>> For additional commands, e-mail: users-help@tapestry.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Asset service issues in GAE
Posted by Alex Kotchnev <ak...@gmail.com>.
Dmitry,
I do have the favicon.ico issue showing up in the logs as well, I'll need
to look into that. Do you have anything special set up for the "static
files" section in the appengine config xml file ?
The problem w/ the failed requests for assets is that they don't show up
in the error log. Every once in a while, I'd get an error like this (which
shouldn't happen - a request to a simple page should never take 30 seconds)
:
Regards,
Alex K
Error for /faq
com.google.apphosting.runtime.HardDeadlineExceededError: This request
(b2c1ec272f017727) started at 2010/04/10 10:56:07.705 UTC and was
still executing at 2010/04/10 10:56:36.820 UTC.
at org.apache.tapestry5.ioc.util.CaseInsensitiveMap.access$008(CaseInsensitiveMap.java:30)
at org.apache.tapestry5.ioc.util.CaseInsensitiveMap$Position.put(CaseInsensitiveMap.java:287)
at org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:355)
at org.apache.tapestry5.ioc.util.CaseInsensitiveMap.put(CaseInsensitiveMap.java:30)
at org.apache.tapestry5.ioc.internal.services.ClassPropertyAdapterImpl.<init>(ClassPropertyAdapterImpl.java:53)
at org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.buildAdapter(PropertyAccessImpl.java:92)
at org.apache.tapestry5.ioc.internal.services.PropertyAccessImpl.getAdapter(PropertyAccessImpl.java:65)
at $PropertyAccess_127e75ce676.getAdapter($PropertyAccess_127e75ce676.java)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyNode(PropertyConduitSourceImpl.java:978)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.infoForPropertyOrMethod(PropertyConduitSourceImpl.java:971)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createGetterAndSetter(PropertyConduitSourceImpl.java:433)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createAccessors(PropertyConduitSourceImpl.java:416)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl$PropertyConduitBuilder.createInstance(PropertyConduitSourceImpl.java:270)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.build(PropertyConduitSourceImpl.java:1254)
at org.apache.tapestry5.internal.services.PropertyConduitSourceImpl.create(PropertyConduitSourceImpl.java:1121)
at $PropertyConduitSource_127e75ce6ee.create($PropertyConduitSource_127e75ce6ee.java)
at org.apache.tapestry5.internal.bindings.PropBindingFactory.newBinding(PropBindingFactory.java:49)
at $BindingFactory_127e75ce6ef.newBinding($BindingFactory_127e75ce6ef.java)
at $BindingFactory_127e75ce6e7.newBinding($BindingFactory_127e75ce6e7.java)
at org.apache.tapestry5.internal.services.BindingSourceImpl.newBinding(BindingSourceImpl.java:81)
at $BindingSource_127e75ce6c5.newBinding($BindingSource_127e75ce6c5.java)
at org.apache.tapestry5.internal.services.PageElementFactoryImpl.newExpansionElement(PageElementFactoryImpl.java:165)
at $PageElementFactory_127e75ce6df.newExpansionElement($PageElementFactory_127e75ce6df.java)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl$15.execute(PageLoaderImpl.java:1024)
at org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
at org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleEmbeddedComponent(ComponentAssemblerImpl.java:157)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl$12.execute(PageLoaderImpl.java:947)
at org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.runActions(ComponentAssemblerImpl.java:207)
at org.apache.tapestry5.internal.pageload.ComponentAssemblerImpl.assembleRootComponent(ComponentAssemblerImpl.java:88)
at org.apache.tapestry5.internal.pageload.PageLoaderImpl.loadPage(PageLoaderImpl.java:159)
at $PageLoader_127e75ce6d1.loadPage($PageLoader_127e75ce6d1.java)
at org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:210)
at org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:99)
at $PagePool_127e75ce6d0.checkout($PagePool_127e75ce6d0.java)
at org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:51)
at $RequestPageCache_127e75ce6cf.get($RequestPageCache_127e75ce6cf.java)
at $RequestPageCache_127e75ce6b8.get($RequestPageCache_127e75ce6b8.java)
at org.apache.tapestry5.internal.services.PageRenderRequestHandlerImpl.handle(PageRenderRequestHandlerImpl.java:52)
at org.apache.tapestry5.services.TapestryModule$33.handle(TapestryModule.java:2262)
at $PageRenderRequestHandler_127e75ce6bb.handle($PageRenderRequestHandler_127e75ce6bb.java)
at $PageRenderRequestHandler_127e75ce6a3.handle($PageRenderRequestHandler_127e75ce6a3.java)
at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handlePageRender(ComponentRequestHandlerTerminator.java:48)
at $ComponentRequestHandler_127e75ce6a8.handlePageRender($ComponentRequestHandler_127e75ce6a8.java)
at org.apache.tapestry5.internal.services.PageRenderDispatcher.dispatch(PageRenderDispatcher.java:45)
at $Dispatcher_127e75ce6aa.dispatch($Dispatcher_127e75ce6aa.java)
at $Dispatcher_127e75ce6a0.dispatch($Dispatcher_127e75ce6a0.java)
at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:255)
at nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper$1.doFilter(RequestFilterWrapper.java:60)
at nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at nu.localhost.tapestry5.springsecurity.services.internal.RequestFilterWrapper.service(RequestFilterWrapper.java:55)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at org.apache.tapestry5.services.TapestryModule$4.service(TapestryModule.java:937)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:926)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:85)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:90)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:81)
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85)
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:103)
at $RequestHandler_127e75ce6a1.service($RequestHandler_127e75ce6a1.java)
at $RequestHandler_127e75ce695.service($RequestHandler_127e75ce695.java)
at org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:206)
at nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:109)
at org.springframework.security.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:83)
at nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
at $HttpServletRequestFilter_127e75ce693.service($HttpServletRequestFilter_127e75ce693.java)
at $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
at nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper$1.doFilter(HttpServletRequestFilterWrapper.java:56)
at nu.localhost.tapestry5.springsecurity.services.internal.SpringSecurityExceptionTranslationFilter.doFilterHttp(SpringSecurityExceptionTranslationFilter.java:100)
at org.springframework.security.ui.SpringSecurityFilter.doFilter(SpringSecurityFilter.java:53)
at nu.localhost.tapestry5.springsecurity.services.internal.HttpServletRequestFilterWrapper.service(HttpServletRequestFilterWrapper.java:52)
at $HttpServletRequestHandler_127e75ce697.service($HttpServletRequestHandler_127e75ce697.java)
at nu.loca
On Tue, Apr 13, 2010 at 9:31 AM, Dmitry Gusev <dm...@gmail.com>wrote:
> Hi, Alex
>
> I'm including *.css and *.png by simply using link rel, like this:
>
> <link rel="stylesheet" type="text/css"
> href="/assets/anjlab/cubics/css/cube.css" />
>
> cube.css located here:
>
>
> ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
>
> I also set up regexAuthorizer:
>
> public void contributeRegexAuthorizer(Configuration<String> regex)
> {
> String pathPattern =
> "([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
> regex.add("^anjlab/cubics/css/" + pathPattern);
> regex.add("^anjlab/cubics/images/" + pathPattern);
> regex.add("^anjlab/cubics/js/" + pathPattern);
> regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
> }
>
> I can't say I have any problems with this.
> At least right now in my error list at GAE Admin console I don't have any
> assets related issues.
>
> I have only one page actively using *.css, *.js, etc., here's the
> declarations:
>
> <head>
> <title>Job Analytics - Ping Service</title>
> <link rel="stylesheet" type="text/css" href="/css/all.css" />
> <link rel="icon" type="image/png" href="/favicon.png" />
> <link rel="stylesheet" type="text/css"
> href="/assets/anjlab/cubics/css/cube.css" />
> <link rel="stylesheet" type="text/css" href="/css/analytics.css" />
> <script type="text/javascript"
> src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
> <script type="text/javascript"
> src="/assets/anjlab/cubics/js/cube.js"></script>
> <!--[if IE]><script language="javascript" type="text/javascript"
> src="excanvas.min.js"></script><![endif]-->
> <script type="text/javascript" src="/js/jquery.flot.js"></script>
> <script type="text/javascript" src="/js/jquery.flot.pie.js"></script>
> <script type="text/javascript" src="/js/analytics.js"></script>
> </head>
>
> p.s.
> One issue I have though is '/favicon.ico' problem :)
>
> On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com> wrote:
>
> > Daniel,
> > I do try to watch out for T5/GAE related posts on this list and try to
> > respond to the best of my ability. I would blog about this more if I
> > weren't
> > as swamped with things to do.
> >
> > I would be interested in hearing from other folks (e.g. Dmitry) that
> have
> > deployed on GAE - in previous questions relating to this issue, folks had
> > mentioned that they don't have a problem w/ this, which makes me think
> that
> > I might have something configured incorrectly (although I'm not doing
> > special here, other than having a few images loaded from the
> stylesheet).
> > I
> > do use the AssetAuthorizer (that was eventually added to 5.2) and that's
> > another possible failure point (e.g. if for whatever reason, the
> > authorization fails in some cases and denies access).
> >
> > On the other hand, serving these assets as static content has dropped
> my
> > CPU usage - I had an cron job watching the site and keeping it warm (so
> > that
> > GAE doesn't swap it out), which was using up about 40% of the free CPU
> > quota
> > - so far, the CPU usage should be about 20% lower.
> >
> > Regards,
> >
> > Alex Kotchnev
> >
> > On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dh...@googlemail.com>
> > wrote:
> >
> > > Hi Alex,
> > >
> > > thanks for that follow-up post. Since I'm going to develop with T5 on
> GAE
> > > as well, this will be in the back of my head as a potential cave-at.
> I'll
> > be
> > > interested in any further findings regarding GAE since it seems that
> > > Tapestry is better tailored towards this particular platform (compared
> to
> > > Wicket).
> > >
> > > Best regards
> > > Daniel
> > >
> > > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> > >
> > > 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<
> AKochnev@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-unsubscribe@tapestry.apache.org
> > >>> For additional commands, e-mail: users-help@tapestry.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
Re: Asset service issues in GAE
Posted by Dmitry Gusev <dm...@gmail.com>.
Hi, Alex
I'm including *.css and *.png by simply using link rel, like this:
<link rel="stylesheet" type="text/css"
href="/assets/anjlab/cubics/css/cube.css" />
cube.css located here:
ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
I also set up regexAuthorizer:
public void contributeRegexAuthorizer(Configuration<String> regex)
{
String pathPattern =
"([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
regex.add("^anjlab/cubics/css/" + pathPattern);
regex.add("^anjlab/cubics/images/" + pathPattern);
regex.add("^anjlab/cubics/js/" + pathPattern);
regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
}
I can't say I have any problems with this.
At least right now in my error list at GAE Admin console I don't have any
assets related issues.
I have only one page actively using *.css, *.js, etc., here's the
declarations:
<head>
<title>Job Analytics - Ping Service</title>
<link rel="stylesheet" type="text/css" href="/css/all.css" />
<link rel="icon" type="image/png" href="/favicon.png" />
<link rel="stylesheet" type="text/css"
href="/assets/anjlab/cubics/css/cube.css" />
<link rel="stylesheet" type="text/css" href="/css/analytics.css" />
<script type="text/javascript"
src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
<script type="text/javascript"
src="/assets/anjlab/cubics/js/cube.js"></script>
<!--[if IE]><script language="javascript" type="text/javascript"
src="excanvas.min.js"></script><![endif]-->
<script type="text/javascript" src="/js/jquery.flot.js"></script>
<script type="text/javascript" src="/js/jquery.flot.pie.js"></script>
<script type="text/javascript" src="/js/analytics.js"></script>
</head>
p.s.
One issue I have though is '/favicon.ico' problem :)
On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <ak...@gmail.com> wrote:
> Daniel,
> I do try to watch out for T5/GAE related posts on this list and try to
> respond to the best of my ability. I would blog about this more if I
> weren't
> as swamped with things to do.
>
> I would be interested in hearing from other folks (e.g. Dmitry) that have
> deployed on GAE - in previous questions relating to this issue, folks had
> mentioned that they don't have a problem w/ this, which makes me think that
> I might have something configured incorrectly (although I'm not doing
> special here, other than having a few images loaded from the stylesheet).
> I
> do use the AssetAuthorizer (that was eventually added to 5.2) and that's
> another possible failure point (e.g. if for whatever reason, the
> authorization fails in some cases and denies access).
>
> On the other hand, serving these assets as static content has dropped my
> CPU usage - I had an cron job watching the site and keeping it warm (so
> that
> GAE doesn't swap it out), which was using up about 40% of the free CPU
> quota
> - so far, the CPU usage should be about 20% lower.
>
> Regards,
>
> Alex Kotchnev
>
> On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dh...@googlemail.com>
> wrote:
>
> > Hi Alex,
> >
> > thanks for that follow-up post. Since I'm going to develop with T5 on GAE
> > as well, this will be in the back of my head as a potential cave-at. I'll
> be
> > interested in any further findings regarding GAE since it seems that
> > Tapestry is better tailored towards this particular platform (compared to
> > Wicket).
> >
> > Best regards
> > Daniel
> >
> > Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> >
> > 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<AKochnev@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-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Asset service issues in GAE
Posted by Alex Kotchnev <ak...@gmail.com>.
Daniel,
I do try to watch out for T5/GAE related posts on this list and try to
respond to the best of my ability. I would blog about this more if I weren't
as swamped with things to do.
I would be interested in hearing from other folks (e.g. Dmitry) that have
deployed on GAE - in previous questions relating to this issue, folks had
mentioned that they don't have a problem w/ this, which makes me think that
I might have something configured incorrectly (although I'm not doing
special here, other than having a few images loaded from the stylesheet). I
do use the AssetAuthorizer (that was eventually added to 5.2) and that's
another possible failure point (e.g. if for whatever reason, the
authorization fails in some cases and denies access).
On the other hand, serving these assets as static content has dropped my
CPU usage - I had an cron job watching the site and keeping it warm (so that
GAE doesn't swap it out), which was using up about 40% of the free CPU quota
- so far, the CPU usage should be about 20% lower.
Regards,
Alex Kotchnev
On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dh...@googlemail.com> wrote:
> Hi Alex,
>
> thanks for that follow-up post. Since I'm going to develop with T5 on GAE
> as well, this will be in the back of my head as a potential cave-at. I'll be
> interested in any further findings regarding GAE since it seems that
> Tapestry is better tailored towards this particular platform (compared to
> Wicket).
>
> Best regards
> Daniel
>
> Am 13.04.2010 06:23, schrieb Alex Kotchnev:
>
> 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<AKochnev@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Asset service issues in GAE
Posted by Daniel Henze <dh...@googlemail.com>.
Hi Alex,
thanks for that follow-up post. Since I'm going to develop with T5 on
GAE as well, this will be in the back of my head as a potential cave-at.
I'll be interested in any further findings regarding GAE since it seems
that Tapestry is better tailored towards this particular platform
(compared to Wicket).
Best regards
Daniel
Am 13.04.2010 06:23, schrieb Alex Kotchnev:
> 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<AK...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Asset service issues in GAE
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ak...@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 <AK...@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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Asset service issues in GAE
Posted by Alex Kotchnev <ak...@gmail.com>.
Markus,
indeed, you do give up some nice things - for me in particular it's the
ability to package the assets together with the components. The versioning
for css and images is not as important in GAE as it already has built in
versioning of the whole app, and the caching policy is not as agressive as
T5's (the static assets expire in 10 minutes). Regarding localization - for
css it doesn't matter much . For images, localization might be nice if I
wanted to display per-locale images, which will probably be important sooner
rather than later, but not yet.
However, having the pages load every once in a while is a non starter.
So, all in all , you gain quite a bit w/o giving up too much.
Regards,
Alex K
On Tue, Apr 13, 2010 at 3:18 AM, Markus Feindler <Ma...@gmx.de>wrote:
> Well, dont you lose the benfits of localisation and versioning when using
> direct paths? Your files aren't handled by the Asset Dispatcher anymore,
> instead the request handler for static files does the work
>
> >
> > -------- Original-Nachricht --------
> > Datum: Tue, 13 Apr 2010 00:23:57 -0400
> > Von: Alex Kotchnev <ak...@gmail.com>
> > An: Tapestry users <us...@tapestry.apache.org>
> > Betreff: Re: Asset service issues in GAE
> >
> > 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
> > <AK...@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-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>
Re: Asset service issues in GAE
Posted by Markus Feindler <Ma...@gmx.de>.
Well, dont you lose the benfits of localisation and versioning when using
direct paths? Your files aren't handled by the Asset Dispatcher anymore,
instead the request handler for static files does the work
>
> -------- Original-Nachricht --------
> Datum: Tue, 13 Apr 2010 00:23:57 -0400
> Von: Alex Kotchnev <ak...@gmail.com>
> An: Tapestry users <us...@tapestry.apache.org>
> Betreff: Re: Asset service issues in GAE
>
> 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
> <AK...@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-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: Asset service issues in GAE
Posted by Alex Kotchnev <ak...@gmail.com>.
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 <AK...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>