Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HPCC-14091 Redis plugin Readme typos #7700

Closed
wants to merge 1 commit into from
Closed

HPCC-14091 Redis plugin Readme typos #7700

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
16 changes: 8 additions & 8 deletions plugins/redis/README.md
View file
Open in desktop
Expand Up @@ -26,7 +26,7 @@ plugin functions will not work when setting with an expiration for a version les
Getting started
---------------

The server can be started by typing `redis-server` within a terminal. To run with with a non-default configuration run as `redis-server redis.conf`, where
The server can be started by typing `redis-server` within a terminal. To run with a non-default configuration run as `redis-server redis.conf`, where
redis.conf is the configuration file supplied with the redis-server package.

For example, to require the server to **password authenticate**, locate and copy redis.conf to a desired dir. Then locate and alter the 'requirepass' variable within the file.
Expand Down Expand Up @@ -93,7 +93,7 @@ The core points to note here are:
127.0.0.1:6379 is used. *Note:* 6379 is the default port for **redis-server**.
* `UNSIGNED timeout` has units *ms* and has a default value of 1 second. This is not a timeout duration for an entire plugin call but rather that set for each
communication transaction with the redis server. *c.f.* 'Behaviour and Implementation Details' below.
* `UNSIGNED expire` has units seconds and a default of **0**, i.e. *forever*.
* `UNSIGNED expire` has units ms and a default of **0**, i.e. *forever*.

###The redisServer MODULE
To avoid the cumbersome and unnecessary need to constantly pass `options` and `password` with each function call, the module `redisServer` can be imported to effectively
Expand All @@ -111,8 +111,8 @@ The notion of a *database* within a redis cache is a that of an UNSIGNED INTEGER
myRedis.SetString('myKey', 'foo', 0);
myRedis.SetString('myKey', 'bar', 1);

myRedis.GetString('myKey', 'foo', 0);//returns 'foo'
myRedis.GetString('myKey', 'bar', 1);//returns 'bar'
myRedis.GetString('myKey', 0);//returns 'foo'
myRedis.GetString('myKey', 1);//returns 'bar'
```
*Note:* that the default database is 0.

Expand Down Expand Up @@ -147,7 +147,7 @@ SEQUENTIAL(

//If the key does not exist it will 'lock' the key and retrun an empty STRING.
STRING value := myRedis.GetOrLockString('supercali- what?');
//All locking.Set<type>() return the value passed in as the 2nd parameter.
//All SetAndPublish<type>() return the value passed in as the 2nd parameter.
IF (LENGTH(value) == 0, myRedis.SetAndPublishString('supercali- what?', myFunc('poppins', 3)), value);
);
```
Expand All @@ -157,13 +157,13 @@ Behaviour and Implementation Details
A few notes to point out here:
* PUB-SUB channels are not disconnected from the keyspace as they are in their native redis usage. The key itself is used as the lock with its value being set as the channel to later
PUBLISH on or SUBSCRIBE to. This channel is a string, unique by only the *key* and *database*, prefixed with **'redis_ecl_lock'**.
* The lock itself is set to expire with a duration equal to the `timeout` value passed to the `locking.Exists(<key>` function (default 1s).
* It is possible to manually 'unlock' this lock (`DELETE` the key) via the `locking.Unlock(<key>)` function. *Note:* this function will fail on any communication or reply error however,
* The lock itself is set to expire with a duration equal to the `timeout` value passed to `GetOrLock<type>` (default 1s).
* It is possible to manually 'unlock' this lock (`DELETE` the key) via the `Unlock(<key>)` function. *Note:* this function will fail on any communication or reply error however,
it will **silently fail**, leaving the lock to expire, if the server observes any change to the key during the function call duration.
* When the *race-winner* publishes, it actually publishes the value itself and that any subscriber will then obtain the key-value in this fashion. Therefore, not requiring an
additional `GET` and possible further race conditions in doing so. *Note:* This does however, mean that it is possible for the actual redis `SET` to fail on one client/process,
have the key-value received on another, and yet, the key-value still does not exist on the cache.
* At present the 'lock' is not as such an actual lock, as only the `locking.Get<type>` functions acknowledge it. By current implementation it is better thought as a flag for
* At present the 'lock' is not as such an actual lock, as only the `GetOrLock<type>` functions acknowledge it. By current implementation it is better thought as a flag for
`GET` to wait and subscribe. I.e. the locked key can be deleted and re-set just as any other key can be.
* Since the timeout duration is not for an individual plugin call but instead that waiting for each reply from the server, the actual possible maximum timeout duration differs from
various functions within this plugin, i.e. some functions do more than others. Below is a table for each of the plugin functions (or catagories of) including the maximum possible and
Expand Down