{"action":"created","issue":{"url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/145","repository_url":"https://api.github.com/repos/openresty/lua-resty-redis","labels_url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/145/labels{/name}","comments_url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/145/comments","events_url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/145/events","html_url":"https://github.com/openresty/lua-resty-redis/issues/145","id":327651554,"node_id":"MDU6SXNzdWUzMjc2NTE1NTQ=","number":145,"title":"redis.lua subscribe/punsubscribe BUG！","user":{"login":"aureolex","id":11733063,"node_id":"MDQ6VXNlcjExNzMzMDYz","avatar_url":"https://avatars1.githubusercontent.com/u/11733063?v=4","gravatar_id":"","url":"https://api.github.com/users/aureolex","html_url":"https://github.com/aureolex","followers_url":"https://api.github.com/users/aureolex/followers","following_url":"https://api.github.com/users/aureolex/following{/other_user}","gists_url":"https://api.github.com/users/aureolex/gists{/gist_id}","starred_url":"https://api.github.com/users/aureolex/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aureolex/subscriptions","organizations_url":"https://api.github.com/users/aureolex/orgs","repos_url":"https://api.github.com/users/aureolex/repos","events_url":"https://api.github.com/users/aureolex/events{/privacy}","received_events_url":"https://api.github.com/users/aureolex/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-05-30T09:38:41Z","updated_at":"2018-05-30T18:52:35Z","closed_at":null,"author_association":"NONE","body":"hellow agentzh\r\n\r\nJust looked at the openresty redis.lua code, found a problem, `unsubscribe` / `punsubscribe` redis channel, will unsubscribe to the corresponding channel\r\nHowever, if there are other places in a redis instance that are `subscribed` to other channels, as long as there is any place `unsubscribing` to their own corresponding channel, then all other subscription channels will not receive data, and in fact these channels are still in the subscription state.\r\nThe redis.lua code is analyzed as follows:\r\nIn line 262, the `_check_subscribed` function means that when the number of unsubscribing channels currently subscribed is 0,` self._subscribed = false`, and the problem lies here.\r\nIf a code logic inside the same redis instance uses ngx.thread to enable multiple coroutines to call the channel corresponding to the subscribe subscription respectively, the problem occurs. The number of subscribers per channel is 1 as long as one channel is canceled. The number is 0, so the BUG of 262 lines of code `_check_subscribed` function comes, sets `self._subscribed` to `false`, and looks at the function\r\nFunction\r\n\r\n```\r\nfunction _M.read_reply(self)\r\n    local sock = rawget(self, \"_sock\")\r\n    if not sock then\r\n        return nil, \"not initialized\"\r\n    end \r\n\r\n    if not rawget(self, \"_subscribed\") then\r\n        return nil, \"not subscribed\"\r\n    end \r\n\r\n    local res, err = _read_reply(self, sock)\r\n    _check_subscribed(self, res)\r\n\r\n    return res, err \r\nend\r\n```\r\n\r\nThis code blocks the other subscription channels from receiving data\r\n```\r\n    if not rawget(self, \"_subscribed\") then\r\n        return nil, \"not subscribed\"\r\n    end \r\n```\r\nThis is a manslaughter. It kills other channels that have not been unsubscribed to receive normal data.\r\n\r\nThe above content translates Chinese into English using https://translate.google.com\r\n\r\nsender email : aureolex@126.com"},"comment":{"url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/comments/393276402","html_url":"https://github.com/openresty/lua-resty-redis/issues/145#issuecomment-393276402","issue_url":"https://api.github.com/repos/openresty/lua-resty-redis/issues/145","id":393276402,"node_id":"MDEyOklzc3VlQ29tbWVudDM5MzI3NjQwMg==","user":{"login":"agentzh","id":56241,"node_id":"MDQ6VXNlcjU2MjQx","avatar_url":"https://avatars1.githubusercontent.com/u/56241?v=4","gravatar_id":"","url":"https://api.github.com/users/agentzh","html_url":"https://github.com/agentzh","followers_url":"https://api.github.com/users/agentzh/followers","following_url":"https://api.github.com/users/agentzh/following{/other_user}","gists_url":"https://api.github.com/users/agentzh/gists{/gist_id}","starred_url":"https://api.github.com/users/agentzh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/agentzh/subscriptions","organizations_url":"https://api.github.com/users/agentzh/orgs","repos_url":"https://api.github.com/users/agentzh/repos","events_url":"https://api.github.com/users/agentzh/events{/privacy}","received_events_url":"https://api.github.com/users/agentzh/received_events","type":"User","site_admin":false},"created_at":"2018-05-30T18:52:35Z","updated_at":"2018-05-30T18:52:35Z","author_association":"MEMBER","body":"@aureolex This does not look like a bug to me but a misuse. If you have multiple light threads to read at the same time, you need separate `resty.redis` object instances for each light thread to read (i.e., separate TCP connections to the redis server). It makes no sense for multiple light threads to read from the same TCP connection to the redis server at the same time."}}
{"actor":{"display_login":"agentzh"}}