Re: Recompiling of .less file triggered in prod unexpectedly

Thank you Cezary. This is invaluable. As a first step I=E2=80=99ve added =
some logging of the caching to see whether this is the culprit.

Geoff

> On 25 Oct 2019, at 7:38 am, Cezary Biernacki <[email protected]> =
wrote:
>=20
> 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.
>=20
> 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").
>=20
> 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.
>=20
> Best regards,
> Cezary
>=20
>=20
>=20
> On Thu, Oct 24, 2019 at 11:18 PM JumpStart <
> [email protected]> wrote:
>=20
>> That=E2=80=99s great information. So is the solution to precompile =
them for
>> production, or to override SRSCachingInterceptor, or something else
>> altogether?
>>=20
>>> On 24 Oct 2019, at 11:09 pm, Cezary Biernacki <[email protected]>
>> wrote:
>>>=20
>>> 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). In
>>> the development mode Tapestry also caches compilations in a =
temporary
>>> directory, but unfortunately this mechanism is disabled in the =
production
>>> mode
>>> (see
>> =
org.apache.tapestry5.internal.webresources.ResourceTransformerFactoryImpl#=
createCompiler).
>>>=20
>>> Cezary
>>>=20
>>>=20
>>> On Thu, Oct 24, 2019 at 2:57 AM JumpStart <
>>> [email protected]> wrote:
>>>=20
>>>> I=E2=80=99m observing that after startup, and then after every 20 =
minutes 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.
>>>>=20
>>>> 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:
>>>>=20
>>>> @Import(stylesheet =3D { "css/client.less" })
>>>> public class Home extends LoggedIn {
>>>>=20
>>>> I=E2=80=99m using tapestry-webresources-5.4.3.jar.
>>>>=20
>>>> I was expecting this to be a one-time event, on first visit to the =
page
>>>> after startup. Under what circumstances would you expect it to =
happen
>> more
>>>> than once?
>>>>=20
>>>> Regards,
>>>>=20
>>>> Geoff
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>=20
>>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]