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
>
>

Reply via email to