As part of the setting up an audit trail, existing object records that were created before auditing was enabled are stored in referenced records in the tables ODF_AUD_OBJ_INST_CONTEXT and ODF_AUD_OBJ_INST_MAPPINGS.
The method in which these tables are populated results in a large memory, network, and processor overhead on the Clarity application server.
- The web browser failing to return a response or a 'page cannot be displayed' error due to the time taken, whilst data is still changing in the back end.
- The application server performance deteriorating.
- The application server hanging with or without a java.lang.OutOfMemory exception error.
For example, if you have 2 million task records, then as the auditing is being switched on for the first time on this object, it is trying to hold 2 million records in memory whilst posting this quantity each into the two tables mentioned.
Steps to Reproduce:
- Use a large Clarity installation where you have millions of task records and auditing has not been enabled before (or insert millions of tasks distributed to >20,000 projects using XOG)
- Navigate to Admin Tool > Studio > Objects > Task > Audit Trail
- In the first column, select Charge Code and move it to the Selected column for auditing
- Place 60 in the Days box for purging old audit information
- Click 'Save' button
Expected Result: Progress of audit trail enabling to display ongoing until completion and without impact to app service uptime.
Actual Result: Web browser will time out before server responds, server performance will decrease, and the app service will likely go down due to java.lang.OutOfMemory error.
Resolved in Clarity 12.1.1 Generic Patch. Reference TEC553491
Resolved in Clarity 12.1.3 Generic Patch. Reference TEC570813
Issue is still reproduced in Clarity 13.0, 13.1 - status pending
Keywords:CLARITYKB, CLRT-69692, clarity12resolved, clarity13resolved, clarity132resolved.