plugin for fetching cache dump from any node after joining legion

[prymitive]

This plugin allows to fetch copy of cache content from any node joined to legion.
It allows for example to hot-add new SSL frontend server with already populated session cache (you just need to set lower frequency for legion so it joins faster).

Usage:

[uwsgi]
[...]
# define cache
cache2 = name=cache1,items=1000,store=/tmp/lc1.ucache,udp=225.1.1.1:1500,node=225.1.1.1:1500

# define legion as usual
legion = legion1 225.1.1.1:19678 101 bf-cbc:abc
legion-node = legion1 225.1.1.1:19678
legion-join = legion1 cmd:echo legion_joined_hook

# connect legion to cache
legion-cache = legion1 cache1
# set socket address advertised to other nodes using legion scroll
legion-cache-dump-socket = 127.0.0.1:3001

Please review.

[unbit]

what about simplyfing it for being only a legion action ?

[uwsgi]
[...]
# define cache
cache2 = name=cache1,items=1000,store=/tmp/lc1.ucache,udp=225.1.1.1:1500,node=225.1.1.1:1500

# define legion as usual
legion = legion1 225.1.1.1:19678 101 bf-cbc:abc
legion-node = legion1 225.1.1.1:19678
legion-join = legion1 cmd:echo legion_joined_hook
# run the action when joining a legion (i think no options are needed, maybe timeout ?)
legion-join = legion1 legion-cache:
# add a plugin-friendly scroll
legion-scroll = legion1 legion-cache:dump-socket=127.0.0.1:3001,cache=cache1

Even the legion-cache name seems a bit too generic, maybe legion-cachedump ?

[prymitive]

sure, if there are no objections to the code I can move it into core/legion.c as an action

I not good at naming things so yes, a better name would be nice ;)

• legion-cache-dump
• legion-cache-fetch
• legion-cache-sync
  (?)

I would love if scroll code be more structured, simple key:value would be enough. So we would have:

legion-scroll = legion1 legion-cache dump-socket=127.0.0.1:3001,cache=cache1

and action would fetch "legion-cache" entry from scroll.
But this can be handled inside action without much trouble, so it's more of a design choice rather than technical issue

[unbit]

it can remain an external plugin (it will be good even as a reference for cache and legions usage in plugins) Just remove the options in favour of rawly setting the scroll

[prymitive]

ok, I'll push update later, is legion-cache-fetch as a name for action and legion_cache_fetch as a name for plugin ok?

[unbit]

yes it's ok

[prymitive]

Pushed stripped version of plugin, now it's just an action for legion subsystem.

Full example:

lc1.ini

[uwsgi]

plugin = legion_cache_fetch

master = true
http = :8081
socket = 127.0.0.1:3001
stats = :2101
wsgi-file = tests/staticfile.py

cache2 = name=cache1,items=1000,store=/tmp/lc1.ucache,udp=225.1.1.1:1500,node=225.1.1.1:1500

legion = legion1 225.1.1.1:19678 101 bf-cbc:abc
legion-node = legion1 225.1.1.1:19678
legion-join = legion1 legion-cache-fetch:cache1
legion-scroll = legion1 dump-socket=127.0.0.1:3001

lc2.ini

[uwsgi]

plugin = legion_cache_fetch

master = true
http = :8082
socket = 127.0.0.1:3002
stats = :2102
wsgi-file = tests/staticfile.py

cache2 = name=cache1,items=1000,store=/tmp/lc2.ucache,udp=225.1.1.1:1500,node=225.1.1.1:1500

legion = legion1 225.1.1.1:19678 101 bf-cbc:abc
legion-node = legion1 225.1.1.1:19678
legion-join = legion1 legion-cache-fetch:cache1
legion-scroll = legion1 dump-socket=127.0.0.1:3002

[unbit]

is not enough to use the lord scroll directly ? (without iterating all the nodes)

If we have a lord its up by definition

[prymitive]

each node has different data in its own scroll, every node puts its own ip:port address of uwsgi socket it has spawned, so I iterate so that cache-sync will try to fetch dump from all nodes.
if node A is lord and it fails right after node B joins, than node B would only make single unsuccessful attempt to fetch cache dump, if I first make a list of all node and pass it to node B, then even if lord manages to fail before or during cache-sync, sync handler will be able to try fetching it from another node.

[unbit]

ok, seems fine but you should free the memory allocated by the kvlist parser for the cachedump item

[prymitive]

Do you mean char *dump_socket ?
It seems that this is not copy but rather reference, freeing it will corrupt items on uc->sync_nodes;
I will be free if I need to update uc->sync_nodes with new list.

[unbit]

effectively the action is run only one time per startup, i can merge as is, maybe in the future we can improve it to not leak memory (the string_list too is not freed)

[prymitive]

I'll fix leaks today/tomorrow morning