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
