[MAGNOLIA-9056] Memory leak when re-registering module Created: 10/Aug/23 Updated: 02/Feb/24 |
|
| Status: | Selected |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Michael Duerig | Assignee: | Oanh Thai Hoang |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | dx-core-6.3 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 2d 4.5h | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| 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)
|
||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Epic Link: | Throughput improvements | ||||||||||||||||
| Work Started: | |||||||||||||||||
| Approved: |
Yes
|
||||||||||||||||
| Description |
|
According to UZH re-registering modules leads to leaked memory.
|
| Comments |
| Comment by Oanh Thai Hoang [ 11/Dec/23 ] |
|
Here is a summary report about improvement of creating hundred of threads in public instance when publishing config.
Step to reproduce: For 6.2 with dx-core-demo-webapp
import info.magnolia.context.MgnlContext; import javax.jcr.Node; import javax.jcr.RepositoryException; import javax.jcr.Session; import javax.jcr.Workspace; public class Test { public static void main(String[] args) { try { Session session = MgnlContext.getSystemContext().getJCRSession("config"); Node node = session.getNode("/modules/multisite/config/sites/travel"); for(int i= 0; i< 100; i++){ String newPath = "/modules/multisite/config/sites/test"+i; Workspace workspace = node.getSession().getWorkspace(); workspace.copy(node.getPath(), newPath); } } catch (RepositoryException e) { e.printStackTrace(); } } }
After applying central threadpool to DelayedExecutor
Note: This issue can't reproduce in 6.3 because DelayedExecutor in 6.3 has been changed and don't use ClockDaemon since See before threads_report-6-12-2.txt Additionally, for 6.3 site is isolated from /config, only accept yaml via site registry. So you have to create yaml file instead. Therefore no real observation in /config/site in public instance can cause restart advance cache multiple time like 6.2 |
| Comment by Michael Duerig [ 12/Dec/23 ] |
|
oanh.thai , I suggest that we reach out to UZH again once |
| Comment by Oanh Thai Hoang [ 02/Feb/24 ] |
|
After
|