Enduro/X Core

- Locally insert/delete. The inserter will overwrite existing rec (upsert)
- Message is broadcasted to event server (broadcast=y)
- Events are following: @CACHENNN_INSERT, @CACHENNN_DELETE
- Optionally we can configure from which nodes to consume events like: (@CACHE011_.*|@CACHE010_INSERT) (this would accept from node 11 any event, from node 10 only insert)
- Cache admin server advertizes correspoding insert/delete services
- event server shall perform only one tpcall per unique service name

Chache events shall be:

@CP/.*/.* -> Listen on any PUT event
@C./.*/.* -> Listen on any event

@CP/1//TESTSVC -> just put, no flags
@CD/22/F/TESTSVC -> Full delete

So format is:

@C<P|D>/<Publisher Node Id>/<Service Name of Cache>

For split brain issues in cluster mode, we could allow to save multiple keys. And we try to fetch all. And to user we return the youngest result. The caller could delete the oldest records.

This should be configurable at cachedb level. For some flag like "timesync"

Cache invalidate strategies by call:

1. We need a invalidate cache settings. Flags would contain "inval". If so then optional invalsvc -> service cache to invalidate. Key would be destination data key. We shall specify invalidx -> index of dest cache number.

2. We also need a "recache" expression. If expression is true, the lookup shall ignore cached data. And overwrite cache data.

tpcached -> shall provide boot-reset function. And monitor for database rules (record expiry) and given interfval

tpcachsv -> Listents to event subscribed to, performs cache updates, delete. Service is "@TPCACHENNN". If message is other than event, then by command codes: we provide backend for xadmin. Where we delete full db, or just key (tpcall). Or provide the record listings in caches with optional data buffer. Record by record is delivered to xadmin in conversational mode. So this way we do not need any aditional API to manage cache records. The user call by it self to manage cache.

if we trigger reset we might want to continue with caching this record.

So that we call one service, it resets other service cache, and saves this service value in cache. So if we trigger theirs, then we continue with ours next save caches. This could be an option to continue with next cache or not.

Test scenarios, test048_cache

1. Simple cache, perform one call, get tstamp. Perform another call, the timestamp shall be the same. Perform another call, to get second record in cache. Use xadmin cs and xadmin cd to dup the results. Before test db shall be cleaned up with xadmin ci <dbname>. Delete records in db -> single key, regexp, full db (xadmin ce variations). Test refresh rule (so that we call and cache record is invalidated)
tmshutdown of service shall make no lookups in cache...

2. Two database cache, operate with second db. First call goes to cache. shutdown the test48sv, call shall fail (does not come from cache), after boot up call the service data shall come from cache (i.e. tpcached have not removed it).

3. Two database cache, operate with second db. First call goes to cache. shutdown the test48sv, call shall fail (does not come from cache), after boot up first call comes from cache, as tpcached have zapped it.

2. Simple cache, use second database, save negative result. Positive shall be ignored. The same timestamp based test. First DB shall be empty, second db shall be filled.

3. timed cache with expiry. Use different service cache and different database. Use flag to drop the db at startup, by ndrxd. Record shall be limited to 10seconds. Add few recs, check they exist in cache with `cs'. wait 10 sec, they should be removed from cache.

4. hits tests. Limit db to 100 recs. Have a key as integer of loop. Each loop cycle we lookup the record in db the number of the counter. Do the loop of i<150 times. Thus wait some time to tpcached process the limits. the check with cs, that keys are have 50..149. As those others have less hits. How ever As this happens in real time, we shall start with 150... down to 0, to gain the hits and itermediate of cached does not kill the results.

5. The fifo test

6. then LRU test

7. Then invalidated ours (refresh rule)

8. Then invalidate theirs

9. Test TPNOCACHELOOK and TPNOCACHEADD flags.

Use different "saveproj" strategies.

Test broadcast functionality:

Test scenarios, test050_domcache - domain cache

Establish cluster:

1. Save data in node1, node2 should be replicated.

2. Save data in node1, node2 should be replicated, data expires, node1 and node2 on both records shall be removed.

3. Save data in node1, delete by key, both nodes must have data deleted.

For unit tests have a "callcache48" utility for cache tests scripting with following properties:

{noformat}
./cachecall <SVCNM> <'{"C_STRING_FIELD":"HELLO"}'> <TSTAMP_FIELD> <got cached result: Y|N - validate> {noformat}

so this will call target server with UBF buffer, check the timestamp in TSTAMP_FIELD, and validate is data cached or not (i.e. stamp must be less than current tstamp then record is cached). we may compare strings, just ensure that alphabetic compare is ok for numbers.

we shall remove from ndrxd cache reset at boot.

Instead we shall add application specific option from tpcachesv with -m <mater_server_id>. So if at tpinit() tpcachesv sees that server id equal to this number, then it will perform cache reset at startup (if bootreset flag is present). Also needs to think about doing this from cold start. I.e. there should be all servers down and then we start. New env variable NDRX_FIRST=1 shall be exported. If it is not starting from cold, then NDRX_FIRST=0.

so if NDRX_FIRST==1 and -m == server_id then reset cache.

well better new binary:

-> tpcachebtsv -> tpcache boot service.

if env NDRX_FULLSTART==1, then reset cache.

cross domain checks can be done in following way:

DOM1 cache svc call, with TPNOCACHELOOK
sleep 1
DOM2 cache svc call, with TPNOCACHELOOK

Then lookup caches, in both machines we shall get result from DOM2 as it is newer.
-> in DB we shall get the DUP records.

Lookup cache records with cache look (standard), the duplicates shall be killed (i.e. timesync is set)

-> then do the test with other DBs, "scandup" enabled, timesync not set.

also the keygroup db shall have back reference to original db. So that if we perform delete of keygroup record, we must kill all records for they keys in data storage db.

Also think about the same db mabe?

Also needs to think how to maximise read-only transactions, for lookup!

On 23/02/18 14:43, Madars Vitolins wrote:

We could have keygroupdb="DB name"

also keygroupfmt="$(LKEY_ID)"

when adding data to database we must append the key group with new key if not in the list.

If doing lookup and keygroupfmt is defined, then firstly find the keygroup rec. Validate that key exists in group and only then perform lookup to DB...

Changes required:

- default rule => Accept always

- default "save" => "*" - all

- default "rsprule" => Only approved

tpcachebtsv at bootreset shall delete also db files! As if file exists some changed settings does not apply!

     args: cs <cache_db_name>|-d <cache_db_name>

cacheshow    Alias for `cs' 

cd    Dump message in cache
     args: cd -d <dbname> -k <key> [-i interpret_result]

cachedump    Alias for `cd' 

ci    Invalidate cache
     args: ci -d <dbname> [-k <key>][-r use_regexp]

cacheinval    Alias for `ci' 

NDRX> 
NDRX> 
NDRX> 
NDRX> cacheshow db01
Syntax error, too few args (min 2, max 3, got 1)!
NDRX> cacheshow db01
Syntax error, too few args (min 2, max 3, got 1)!
NDRX> 

Add standard library function for dropping database file (ndrx_mdb_drop("directory")) -> This would simple delete "lock.edb" and "data.edb".

New feature: we could schedule invalidate for time period. For example cached data header would identify max UTC until which cache shall not be used. And only after this period record is updated and cache could be used again.