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 <cezary...@gmail.com> wrote:
>
> 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 <
> geoff.callender.jumpst...@gmail.com> wrote:
>
>> 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 <cezary...@gmail.com>
>> 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). 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).
>>>
>>> Cezary
>>>
>>>
>>> On Thu, Oct 24, 2019 at 2:57 AM JumpStart <
>>> geoff.callender.jumpst...@gmail.com> wrote:
>>>
>>>> I’m 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.
>>>>
>>>> I’ve 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 = { "css/client.less" })
>>>> public class Home extends LoggedIn {
>>>>
>>>> I’m using tapestry-webresources-5.4.3.jar.
>>>>
>>>> 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?
>>>>
>>>> Regards,
>>>>
>>>> Geoff
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
