[asterisk-bugs] [JIRA] (ASTERISK-25067) Sorcery Caching: Implement a new caching module

[Matt Jordan (JIRA)]

Matt Jordan created ASTERISK-25067:
--------------------------------------

             Summary: Sorcery Caching: Implement a new caching module
                 Key: ASTERISK-25067
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25067
             Project: Asterisk
          Issue Type: Improvement
      Security Level: None
            Reporter: Matt Jordan


h2. Overview

See [Sorcery Caching|https://wiki.asterisk.org/wiki/display/~jcolp/Sorcery+Caching] for more background and information.

This issue is to create a specific sorcery wizard for in-memory caching, {{res_sorcery_memory_cache}}. It should be specified in the same way as existing caching wizards, except that it will provide a smarter set of policies for how items in the cache are managed.

Example configuration:
{code}
[res_pjsip]
endpoint/cache=memory_cache
endpoint=realtime,ps_endpoints
{code}

h2. Implementation

# Create a new module, {{res_sorcery_memory_cache}}. Implement the standard suite of callbacks for a {{ast_sorcery_wizard}} struct. The initial implementation of this can start from {{res_sorcery_memory}}.
# Add configuration options documented on the wiki page. Note that this step is purely to add the hooks necessary to parse the configuration passed in from the {{.open}} callback.
# Implement expiration of objects. If an object is expired, it should be removed from the cache, and the cache should return NULL. The next wizard down that returns a valid object should re-add it to the cache exactly as if it were a new item being added to the cache.
# Add a maximum limit to the size of the cache. Since the underlying container will be an ao2 container, this will require some finesse:
** Look at the container count when adding a new item. If it is under the count, add away.
** If not, perform a lookup on the container based on the oldest known item. This should almost certainly *not* be done using an ao2_callback, as that would require iterating over all the objects, which would be absolute garbage for performance. Instead, an alternate container that organizes the entries by age should be used.
** Get the oldest as mentioned above, remove it from both containers, then add the new one.
# Add staleness. If an item is stale, return it, but queue up a check to see if the next wizard down has it. If that fails, remove the item from the cache (auto-expire it).

*NOTE*: There are other options, but the ones listed above are a bit higher priority than the others on the page. If the others are necessary, they will be implemented as well.

h2. Testing

h3. Initial Caching

Write tests that cover the following:
# Write basic tests for the wizard. Confirm items can be created, retrieved, updated, and deleted using the standard callbacks.
# Create a cache with an expiration time.
** Verify that a non-expired item is retrieved without hitting a backing layer.
** Verify that an expired item is removed from the cache and hits a backing layer.
*** Verify that a backing layer not having the item results in an overall NULL value being returned.
*** Verify that a backing layer having the item results in it being returned, and re-populated in the cache with the correct new expiration time.
# Add a maximum size to the cache (10)
** Add 15 objects, verify that only 10 were created.
** Add 10 objects. Verify the 5 oldest. Add 5 more. Verify that 10 are in the cache, and the 5 oldest were removed.
# Create a cache with staleness.
** Verify that stale objects are returned when retrieved.
*** Verify that a stale object that is still in the backing storage is updated, and that its expiration time is updated.
*** Verify that a stale object that is not in the backing storage is removed from the cache.




--
This message was sent by Atlassian JIRA
(v6.2#6252)