Hi Ben, This is all truly great to know. I think I may draw ideas from both yours and Dmitry’s response.
Thank you, Geoff > On 30 Nov 2021, at 4:40 pm, Ben Weidig <b...@netzgut.net> wrote: > > Hi Geoff, > > we have a multi-tenant/-domain multi-language site that required pre-heated > servers after deployment, so we created a WarmupTaskRunner to run at > startup, which gets contributed different kinds of tasks. > They can either be blocking or just run in the background, depending on > what they do (e.g., pre-heating caches/assets, ensuring indices in MongoDB > are set in dynamic collections, ...). > > In our case, we just call the index pages for all relevant domains with > Apache HttpClient instead of creating the pages and components in Tapestry > itself. > But Dmitry's way is more thoroughly than our method. > > The WarmupTaskRunner is combined with the health checks for HAProxy. > An HttpServletFilter checks for things like "warmup finished" by asking the > WarmupTaskRunner, and "mysql connection pool available", "mongodb > available", etc., and returns an appropriate HTTP status code to HAProxy. > If not 200 is returned, HAProxy takes the server out of rotation. > > Cheers, > Ben > > > On Tue, Nov 30, 2021 at 2:41 AM JumpStart < > geoff.callender.jumpst...@gmail.com> wrote: > >> Hi Dmitry, >> >> That is spectacularly helpful! >> >> We’re about to write a headless smoke test anyway that will visit every >> page. Do you see any downside to using that to do the warmup? >> >> Where do you keep your shared “warmup in progress” flag so that it is >> rapidly accessible on every health check request? >> >> Cheers, >> >> Geoff >> >>> On 30 Nov 2021, at 6:35 am, 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 >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
