On 25.03.20 15:19, Jonathan Yom-Tov wrote:
> Sounds good. What would be the best way of evaluating the result so I can
> cache it?
Buffer the output (e.g. by providing a buffered stream for the response)
I'm not sure if this means that you'll need to wrap the response object,
of if you could just replace its output stream. But in general: In your
filter, make sure you get hold of the output stream and capture its
content before you pass the request along the filter chain. After
returning, obtain the buffer, save it for future use, then dump it on
the original output stream. The commons project has a couple of nice
options (I vaguely remember a TeeOutputStream or similar, which would
automagically be able to keep your current client happy, while also
filling up the buffer)
Olaf
> On Wed, Mar 25, 2020 at 4:03 PM Olaf Kock <tom...@olafkock.de> wrote:
>
>> On 25.03.20 14:51, Jonathan Yom-Tov wrote:
>>> I think I phrased my question incorrectly. What I want to do is to cache
>>> the HTML resulting from the JSPs evaluation so I can serve the cached
>>> result. The reason is that I'm working on an application which makes a
>> lot
>>> of requests per page. This makes the page very slow. What I want to do is
>>> to serve some of the requests which build the page out of a cache.
>>> Rewriting the offending endpoints would be a very lengthy process. There
>>> are a lot of them and they're part of a legacy project which is very hard
>>> to get into.
>>>
>>> So is pre-evaluating the JSPs the correct strategy or is there a
>> better way?
>>
>>
>> well, with that, you could either request the JSP yourself and cache the
>> result. To do this transparently, you could implement a ServletFilter
>> that caches the result if it senses a cacheable request and (on
>> subsequent requests) transparently serves the value from cache as long
>> as the criteria ("should re-evaluate") holds.
>>
>> Bonus points for taking care of concurrent requests during
>> re-evaluation, and pause them during the time a re-evaluation is done in
>> a different request.
>>
>> Olaf
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
