[MGNLCACHE-199] Excessive cache flush due to wrong event pattern matching Created: 16/Apr/18 Updated: 28/Feb/20 Resolved: 28/Feb/20 |
|
| Status: | Closed |
| Project: | Cache Modules |
| Component/s: | cache core |
| Affects Version/s: | 5.6.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Viet Nguyen | Assignee: | Unassigned |
| Resolution: | Not an issue | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
| Date of First Response: |
| Description |
|
| Comments |
| Comment by Viet Nguyen [ 16/Apr/18 ] |
|
Changing '/modules/cache/config/contentCaching/uuid-key-mapping/flushPolicy/policies/flushAll@class' from 'info.magnolia.module.cache.FlushAllListeningPolicy' to 'info.magnolia.module.cache.DefaultListeningFlushPolicy' for testing using DefaultListeningFlushPolicy.java |
| Comment by Jan Haderka [ 28/Feb/20 ] |
|
Is there a support ticket this is related to for more details? Looking at how the flush policies are instantiated, the first number indicates that we wait for up to 5 seconds since receiving the last event before processing it in case there are further events incoming so they can be processed together. The second number indicates that we wait up until 30 seconds in case events keep coming.
final EventListener listener = ObservationUtil.instanciateDeferredEventListener(cacheCleaner, 5000, 30000);
Looking at the log in this ticket: 1ms passed between all those events, so they were all processed by same event processing and resulted in single call to preHandleEvents thus to single cache flush. This can be confirmed by observing the log further and seeing only 2 invocations of preHandleEvents denoted by log ... Handling pre-event ... One call was for default content cache and one for UUID-key mapping cache. As for the other request that cache should not be flushed based on last modification date change of the ticket, this is invalid as well as it is common practice to query content based on the date changes or exclude or prioritize in results based on modification date hence such change is valid reason for flushing the cache. Closing this ticket as invalid. |