From 118e1b8df1f02213b87491e9b8583b844560f27d Mon Sep 17 00:00:00 2001 From: Rebeccah Date: Tue, 16 Jun 2020 17:53:07 -0400 Subject: removing memchache mentions in comments remove memcached folder as it is no longer needed, also address a couple grammatical errors --- docs/tasks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'docs/tasks.md') diff --git a/docs/tasks.md b/docs/tasks.md index 4fea6d4ef4..13d7f969b6 100644 --- a/docs/tasks.md +++ b/docs/tasks.md @@ -263,9 +263,9 @@ This entire process enables a response of a `202 Accepted`, where instead of wai #### Handle Setting Changes -Any time the user changes a setting in AWX (_e.g._, in `api/v2/settings`), data will be added to or altered in a database. Since querying databases directly can be extremely time-consuming, each node in a cluster runs a local `memcached` server, none of which are aware of each other. They all potentially have different values contained within, but ultimately need to be consistent. So how can this be accomplished? +Any time the user changes a setting in AWX (_e.g._, in `api/v2/settings`), data will be added to or altered in a database. Since querying databases directly can be extremely time-consuming, each node in a cluster runs a local `redis-cache` server, none of which are aware of each other. They all potentially have different values contained within, but ultimately need to be consistent. So how can this be accomplished? -"Handle Setting Changes" provides the solution! This "fanout" task (_i.e._, all nodes execute it) makes it so that there is a single source of truth even within a clustered system. Whenever a database setting is accessed, and that setting's name is not present in `memcached`, it grabs the setting from the database and then populates it in the applicable node's cache. When any database setting gets altered, all of the `memcached` servers on each node needs to "forget" the value that they previously retained. By deleting the setting in `memcached` on all nodes with the use of this task, we assure that the next time it is accessed, the database will be consulted for the most up-to-date value. +"Handle Setting Changes" provides the solution! This "fanout" task (_i.e._, all nodes execute it) makes it so that there is a single source of truth even within a clustered system. Whenever a database setting is accessed, and that setting's name is not present in `redis-cache`, it grabs the setting from the database and then populates it in the applicable node's cache. When any database setting gets altered, all of the `redis-cache` servers on each node needs to "forget" the value that they previously retained. By deleting the setting in `redis-cache` on all nodes with the use of this task, we assure that the next time it is accessed, the database will be consulted for the most up-to-date value. ### Analytics and Administrative Tasks -- cgit v1.2.3