Skip to content

shared dict feature #25

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.

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

Open
alonbg opened this issue Jun 13, 2016 · 15 comments
Open

shared dict feature #25

alonbg opened this issue Jun 13, 2016 · 15 comments

Comments

@alonbg
Copy link

alonbg commented Jun 13, 2016

globally shared dict instance - accesable from both http and stream contexts

@agentzh
Copy link
Member

agentzh commented Jun 13, 2016

@alonbg This is still a TODO and will get addressed in the near future.

@jebabcock
Copy link

Awesome, I was just wondering if something like this exists or was being worked on.I keep my eye out for it then.

@alonbg
Copy link
Author

alonbg commented Aug 1, 2016

@agentzh since http and stream modules have thier own private L state.
I'm curious how are you going to address this.
Thanks!

@agentzh
Copy link
Member

agentzh commented Aug 1, 2016

@alonbg Well, shared memory zones are not coupled with Lua VM states at all. So sharing can be achieved by a higher-level shared nginx C module which can be called something like ngx_meta_lua_module :)

@rshriram
Copy link

Silly question: if its globally shared across the nginx server instance, why does one need explicit support for shared dict in http or stream context? Shouldn't the nginx architecture (wrt data sharing across workers) be independent of the type of contexts (http/tcp/udp)? The same applies to nginx variables as well. otherwise it seems like awful duplication of effort. Please correct me if my assumptions about nginx internal arch are incorrect.

@agentzh
Copy link
Member

agentzh commented Aug 10, 2016

@rshriram Well, the shm zone API is generic, but it has to be exposed and get utilized by different nginx subsystems, for obvious reasons. Regarding code duplication, well, nginx prefers best performance over avoiding code duplication. Still, I'm devising a macro-level mechanism to share as much code as possible between ngx_stream_lua_module and ngx_http_lua_module, at least from the developers' perspective (from the C compiler's perspective code is still kinda duplicate though with important differences). Well, your question actually goes beyond my decisions, since it's more about nginx core's architectural design.

@alonbg
Copy link
Author

alonbg commented Aug 24, 2016

@agentzh
Silly idea, if I may: couldn't we extend the current http/stream shm zone implementation to have a global/local toggle ? (e.g. lua_shared_dict from_http 10m g; g = global)
And if needed ngx_meta_lua_module would be a passive bridge between the two modules. A module (be it stream or http) will register it's global shm zone in ngx_meta_lua_module for the other module to add to it's own lmcf->shm_zones. Then again this just might be a really wrong idea :)

And anyway, If you think it's worth kick starting a repo with some boiler plate skeleton code i'll happily fork :)

What do you think ?

@agentzh
Copy link
Member

agentzh commented Aug 24, 2016

@alonbg I'm not sure about the details at this point, unfortunately. But you're more than welcome to fiddle about with various different options in your own branches and send us feedback :)

@alonbg
Copy link
Author

alonbg commented Sep 7, 2016

@agentzh here you go :) Please have a look.

@rohitjoshi
Copy link

👍 waiting for this feature so I don't have to build a standalone TCP server and move cache to Redis :(

@jamessoubry
Copy link

+1

@zerog2k
Copy link

zerog2k commented Feb 6, 2019

👍

@turbo
Copy link

turbo commented Jul 1, 2019

@agentzh It's been a few years, any news?

@rohitjoshi
Copy link

Any update on this?

@thibaultcha
Copy link
Member

Here is my proposal: openresty/meta-lua-nginx-module#76

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants