[MGNLPN-629] Cache shows issues when using personalization Created: 27/Apr/22 Updated: 26/Aug/22 |
|
| Status: | Open |
| Project: | Magnolia Personalization |
| Component/s: | None |
| Affects Version/s: | 2.0.15 |
| Fix Version/s: | None |
| Type: | Story | Priority: | Neutral |
| Reporter: | Roberto Gaona | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| 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)
|
||||
| Date of First Response: | |||||
| Epic Link: | AuthorX Support | ||||
| Team: | |||||
| Description |
|
When using Ehcache3, errors related to any personalized content appears on the logs (MgnlLockTimeout). When changing the personalization specific classes back to the default ones, the errors disappeared and the cache worked without complications. This makes us think that there may be issues with the cache when using personalization and should get investigated. |
| Comments |
| Comment by Roman Kovařík [ 28/Apr/22 ] |
|
There is a loat of personalized content, as per customers comments which result in much more request. So this doesn't necessarily is a problem in p13n.
|