Yep, that was the solution. I now cache hard references to the .less resources
instead of SoftReferences. The page that uses the .less file no longer lags
(except the first time after startup).
In fact, I’m considering doing it for all assets, because I’m not clear on
there being any benefit to
Thank you Cezary. This is invaluable. As a first step I’ve added some logging
of the caching to see whether this is the culprit.
Geoff
> On 25 Oct 2019, at 7:38 am, Cezary Biernacki wrote:
>
> Assuming that my suggestion is correct, the simplest solution would be to
> give more heap space to J
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 (
That’s great information. So is the solution to precompile them for production,
or to override SRSCachingInterceptor, or something else altogether?
> On 24 Oct 2019, at 11:09 pm, Cezary Biernacki wrote:
>
> Tapestry caches compiled files in memory using SoftReference<> so it is
> possible for t
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
