[OPENAM-6748] Improve mechanics of the notification cache Created: 02/Sep/15  Updated: 19/Jul/19  Resolved: 31/Jan/18

Status: Resolved
Project: OpenAM
Component/s: SDK
Affects Version/s: 13.0.0
Fix Version/s: 13.5.3, 6.0.0, 14.1.2, 5.5.2

Type: Improvement Priority: Minor
Reporter: Ian Packer [X] (Inactive) Assignee: Adam Heath
Resolution: Fixed Votes: 1
Labels: Backlog, EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates OPENAM-11770 amster import-config overloads AM's JVM Resolved
Regression
caused OPENAM-10325 Memory leak while running stability r... Resolved
Relates
is related to OPENAM-11770 amster import-config overloads AM's JVM Resolved
Target Version/s:
Sprint: AM Sustaining Sprint 44, AM Sustaining Sprint 45, AM Sustaining Sprint 46, AM Sustaining Sprint 47
Story Points: 3
Support Ticket IDs:

 Description   

Currently the notification cache is designed to hold com.sun.am.event.notification.expire.time minutes worth of notification objects. The default and minimum value for this is 30 minutes.

Since the source of new notifications can be a completely external source (i.e persistent search results from a remote datastore) it might be useful to have further controls/measures on this cache to prevent OpenAM becoming overwhelmed with notification data in the event of an unusual external event.

Currently, if a very large set of changes gets pushed through the persistent search mechanism (could be a large data migration/import or a misbehaving remote system) OpenAM will keep storing notifications with no upper limit on total memory used for this cache. As long as network/CPU performance is high enough OpenAM can easily receive too many notifications to store in memory over a 30 minute period.

An additional mechanism to prevent the server running itself out of memory would be a useful addition for robustness purposes. Additionally, 30 minutes seems like quite a long minimum value for this cache - are there any reasons it couldn't be decreased to 10 or 15 minutes?



 Comments   
Comment by Peter Major [X] (Inactive) [ 09/Jan/17 ]

Phill Cunnington is 14 still susceptible for these kind of issues with the new notification system?

Comment by Adam Heath [ 30/Jan/18 ]

Made some changes here to improve the caching logic slightly so that if the cache size is 0 OR no notification URLs are registered then no cache will be populated. Previously the logic here required the cache size to be 0 AND no URLs registered before the cache was ignored.

0 is the minimum value which can be provided for this setting - which will result in this cache not being used at all. Default value for this setting has also now been modified to be 5 minutes using the serverDefaults.properties file, as this was determined to be a more reasonable value to use - this also matches the value being used in the functional tests.

Setting this value via the serverdefaults.properties file means that this value will be updated when going through the upgrade process (if the value has not previously been set).

Hopefully these changes should improve things here for customers by reducing this cache from being populated unnecessarily.

Jonathan Thomas - unsure what we want to do with this JIRA going forward. Taking into consideration it's age and the changes made above - perhaps these changes are significant enough to mark the bug as resolved, or do you feel any further work is required here?

Comment by Jonathan Thomas [ 31/Jan/18 ]

I think it is good to be resolved as this cache being unnecessarily used and overwhelmed with notification data in the event of an unusual external event (time limit is less) should be fixed.

Comment by Adam Heath [ 31/Jan/18 ]

Marking as 'Fixed' based on the improvements and comments made above.

Generated at Fri Nov 27 06:11:31 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.