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.

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

resty-lock inoperative in init_worker_by_lua_file #18

Open
chopper-poet opened this issue Feb 1, 2018 · 5 comments
Open

resty-lock inoperative in init_worker_by_lua_file #18

chopper-poet opened this issue Feb 1, 2018 · 5 comments

Comments

@chopper-poet
Copy link

hi,agentzh
I used lock:lock on init_worker_by_lua_file,but inoperative.
here is my code
`local resty_lock = require "resty.lock"
local lockOpts = {["exptime"]="5",["timeout"]="0"}
local lock, err = resty_lock:new("MY_LOCKS",lockOpts)
if not lock then
ngx.log(ngx.ERR,"failed to create lock:"..tostring(err))
return
end

local elapsed, err = lock:lock('lock_key')
if not elapsed then
ngx.log(ngx.DEBUG,"failed to acquire the lock: "..tostring(err))
return
else
ngx.log(ngx.DEBUG,"get lock success")
return
end
)`

My nginx has 4 workers and i set timeout=0 for get lock operation,but still display 4 'get lock success'

@agentzh
Copy link
Member

agentzh commented Feb 2, 2018

@panjunDev This is a known limitation. See https://github.com/openresty/lua-resty-lock/#limitations

@fengshenyun
Copy link

hi, agentzh
i have 4 worker process, i need one to load data, before this worker completed load data, other workers should not work(can't process request). how can i do it?

@agentzh
Copy link
Member

agentzh commented Apr 9, 2018

@fengshenyun Sounds like you should really load the data in the init_by_lua* handler instead (i.e., in the master process before forking off workers).

@fengshenyun
Copy link

because of i need load data from a http server, init_by_lua* is not allow do this.

@agentzh
Copy link
Member

agentzh commented Apr 10, 2018

@fengshenyun You can try using the blocking LuaSocket library to do this as long as its timeout protection is good enough. It does not matter to block in the master process for a bit (just not too long). But yeah, we'll eventually enable the cosocket API in the context of init_by_lua* context. Before that, you can use the blocking approach as a workaround.

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

3 participants