Re: Recompiling of .less file triggered in prod unexpectedly
Cezary Biernacki <[email protected]> Fri, 25 Oct 2019 01:38:58 +0200
| Newsgroups | gmane.comp.java.tapestry.user |
|---|---|
| Message-ID | <CAE26fNhOy2As_A44UHXfUuHaV1c0Mv1=Mcm8o2YsQq38xsA74g@mail.gmail.com> |
--0000000000003ded830595b08a6b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Assuming that my suggestion is correct, the simplest solution would be to
give more heap space to JVM if there is enough RAM on machines you are
deploying.
Otherwise, I would attempt to create a StreamableResourceSource decorator
that would cache only selected resources that are heavy to compute (e.g.
less files in your case), but otherwise not very memory consuming in a
ConcurrentMap using normal references (i.e. not SoftReference). As there is
already a stack of decorators for SRS (see
org.apache.tapestry5.modules.AssetsModule) you should be careful how to
order that new decorator. Try @Order("before:GZIpCompression",
"after:CacheCompressed").
But in longer term, some way to precompile files for the production would
be more sustainable. I would a consider a solution that adds
another StreamableResourceSource decorator (or a ResourceTransformerFactory
decorator) which works in two modes, In the first mode it saves streamable
resources to a specified directory on the file system, in the second mode
it retrieves cached data from a JAR (using Java's Resource). During the
build process a script would start the application in the first mode,
trigger compilation of key assets, and finally pack it to a JAR. In the
production the second mode could be be used.
Best regards,
Cezary
On Thu, Oct 24, 2019 at 11:18 PM JumpStart <
[email protected]> wrote:
> That=E2=80=99s great information. So is the solution to precompile them f=
or
> production, or to override SRSCachingInterceptor, or something else
> altogether?
>
> > On 24 Oct 2019, at 11:09 pm, Cezary Biernacki <[email protected]>
> wrote:
> >
> > Tapestry caches compiled files in memory using SoftReference<> so it is
> > possible for the garbage collector to remove them (see
> > org.apache.tapestry5.internal.services.assets.SRSCachingInterceptor). I=
n
> > the development mode Tapestry also caches compilations in a temporary
> > directory, but unfortunately this mechanism is disabled in the producti=
on
> > mode
> > (see
> org.apache.tapestry5.internal.webresources.ResourceTransformerFactoryImpl=
#createCompiler).
> >
> > Cezary
> >
> >
> > On Thu, Oct 24, 2019 at 2:57 AM JumpStart <
> > [email protected]> wrote:
> >
> >> I=E2=80=99m observing that after startup, and then after every 20 minu=
tes or so
> -
> >> actually, it seems to be quite variable - the first page after login
> will
> >> take 20 or more seconds to be displayed. The rest of the time it is
> almost
> >> instantaneous.
> >>
> >> I=E2=80=99ve run a sampler over it during one of these 20+ sec periods=
and it
> >> seems to be spending all its time in the Less compiler. The page is
> using
> >> @Import:
> >>
> >> @Import(stylesheet =3D { "css/client.less" })
> >> public class Home extends LoggedIn {
> >>
> >> I=E2=80=99m using tapestry-webresources-5.4.3.jar.
> >>
> >> I was expecting this to be a one-time event, on first visit to the pag=
e
> >> after startup. Under what circumstances would you expect it to happen
> more
> >> than once?
> >>
> >> Regards,
> >>
> >> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--0000000000003ded830595b08a6b--