I think you’d want to make it a configuration option, so that development can still come up quickly, but that sounds great for production.
I’ve spent some time bouncing between Dmitry and Ben’s approaches. With the latter I simplified it with Jsoup, but there are considerable limitations to what can be preloaded that way. Dmitry, I have tried to flesh out what you’ve done, but I think my knowledge of Tapestry internals is holding me back. You seem to have taken a really deep dive! Is there any code that you’d feel comfortable sharing? Cheers, Geoff > On 4 Dec 2021, at 6:00 am, Thiago H. de Paula Figueiredo <thiag...@gmail.com> > wrote: > > Hi! > > Today I started wondering about how we could get Tapestry to run under > Quarkus.io, including generating a native executable. Of course, this won't > include bytecode generated in runtime, something many libraries and > frameworks do, Tapestry very much included. Then I researched a bit and > found this: https://quarkus.io/guides/writing-extensions#bytecode-recording. > Basically, it's a hook for you to run the code that will generate bytecode > while the hook records everything (if I got it right). So, to write an > extension for Tapestry, we would need to have every page and and every > service (and maybe some other stuff too) fully realized, since Tapestry-IoC > and Tapestry load mostly everything in a lazy manner. This is something > that could also solve Geoff's question: if we can somehow force Tapestry to > preload everything, then the app is ready and (at least mostly) warm when > the first request is properly served. > > With the code Dmitry shared here, I wonder if you want to collaborate on > implementing this preload feature on Tapestry itself out-of-the-box, > avoiding some ugly workarounds needed since there's no actual support for > that. :) > > Cheers! > > On Mon, Nov 29, 2021 at 7:36 PM Dmitry Gusev <dmitry.gu...@gmail.com> wrote: > >> Hi Geoff, >> >> I don't think there's a simpler way, we're doing something similar. >> >> We created a REST endpoint with tynamo-resteasy which is effectively a load >> balancer health check. >> On the first hit it starts the warmup process on the same request, >> following requests return an error instantly if the initial warmup routine >> is still in progress. >> >> Our warmup logic is heavily based on tapestry internals & reflection, in >> conjunction with eager loading services as described here: >> https://gist.github.com/dmitrygusev/5562739 >> >> Warmup logic is a bit complicated, it's trying to: >> - "touch" each page using ComponentClassResolver.getPageNames() >> - recursively for each component with mixins on a page starting from root >> component, >>> find imported assets via reflection (fields with names starting as >> `importedAssets_`) >>> stream each asset via `StreamableResourceSource` into no-op consumer >> - find JS modules with `ModuleManager` and stream through no-op consumer >> - every JS stack returned from `JavaScriptStackSource` assemble with >> `JavaScriptStackAssembler` and stream through no-op consumer >> - repeat above for each locale/axis >> >> Entire process usually takes 3-5 minute in our setup. >> After it's done we return 200 to the load balancer and the first real >> request is handled with hot caches. >> >> Hope this helps, >> Dmitry >> >> On Mon, Nov 29, 2021 at 9:53 PM JumpStart < >> geoff.callender.jumpst...@gmail.com> wrote: >> >>> Any suggestions on best ways to write a “health check” page to be called >>> by load balancers? >>> >>> My app is getting big, and the traffic is big. If the app fails >> (hopefully >>> never, but it’s a JVM) and the traffic is heavy enough, startup never >> seems >>> to complete - every request times out, the app log goes quiet, and CPU >> goes >>> to 100%. It appears to be due to race conditions possibly involving asset >>> compression, minimising, and first time into the pages. >>> >>> I’m considering having a startup service crawl every page, in every >>> language, in every skinning, before setting a singleton flag that the >>> health check page will read to determine whether the app is ready to >>> receive traffic. >>> >>> Is there a simpler way? >>> >>> Geoff >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> > > > -- > Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
