Issue Summary

This ticket is linked to CONFSERVER-99864. As part of review of L2 cache due to OOM issue, we figured out that almost majority of total L2 queries corresponds to Confluence quick reload plugin and these were in millions. As a quick example, we could see that total L2 cache queries were 4894836 and as part of that, queries related to quick reload plugins were 3769788 alone.

Steps to Reproduce

1. Setup Confluence cluster environment with example site.
2. Capture the PageId for one of the pages.
3. Use curl to push through similar request for different time frames.

   curl -u <username>:<password> <BASE_URL>/rest/quickreload/latest/5570564?since=1747910237096&_=1747907599249
   

Expected Results

We should not add the underlying queries linked to this request to L2 cache as they might not be useful. Typically if the number is in millions, so I guess it just defeats the purpose of caching itself.

Actual Results

Confluence ends up caching both the beloq queries from Confluence reload plugin -

select cast(count as number(10,0)) as col_0_0_ from CONTENT attachment0_ where attachment0_.CONTENTTYPE='ATTACHMENT' and attachment0_.PAGEID=? and (attachment0_.PREVVER is null) and attachment0_.CONTENT_STATUS='current' and attachment0_.LASTMODDATE>?
...
select comment0_.CONTENTID as contentid1_18_, comment0_.HIBERNATEVERSION as hibernateversion2_18_, comment0_.TITLE as title4_18_, comment0_.LOWERTITLE as lowertitle5_18_, comment0_.VERSION as version6_18_, comment0_.CREATOR as creator7_18_, comment0_.CREATIONDATE as creationdate8_18_, comment0_.LASTMODIFIER as lastmodifier9_18_, comment0_.LASTMODDATE as lastmoddate10_18_, comment0_.VERSIONCOMMENT as versioncomment11_18_, comment0_.PREVVER as prevver12_18_, comment0_.CONTENT_STATUS as content_status13_18_, comment0_.PAGEID as pageid14_18_, comment0_.PARENTCOMMENTID as parentcommentid25_18_ from CONTENT comment0_ where comment0_.CONTENTTYPE='COMMENT' and comment0_.PAGEID=? and comment0_.LASTMODDATE>? order by comment0_.LASTMODDATE asc

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available