oknet commented on issue #8635: URL: https://github.com/apache/trafficserver/issues/8635#issuecomment-1044583075
There are 2 TSConts and 2 TSMutex created: - The first at `ts_lua_http_intercept` and `ts_lua_http_server_intercept`, and the handler is `ts_lua_http_intercept_entry` https://github.com/apache/trafficserver/blob/eaf9848fd539d7f42218374b9f65754df943956e/plugins/lua/ts_lua_http_intercept.c#L86-L88 https://github.com/apache/trafficserver/blob/eaf9848fd539d7f42218374b9f65754df943956e/plugins/lua/ts_lua_http_intercept.c#L120-L122 - The second at `ts_lua_http_intercept_process`, and the handler is `ts_lua_http_intercept_handler` https://github.com/apache/trafficserver/blob/eaf9848fd539d7f42218374b9f65754df943956e/plugins/lua/ts_lua_http_intercept.c#L170-L171 At the frame #11, `ts_lua` received `TS_EVENT_NET_ACCEPT` event and the first TSMutex is locked. At the frame #7, `ts_lua` run into the `ts_lua_say` without `TS_EVENT_VCONN_WRITE_READY` event called back, it means the second TSMutex is not locked. Although the current code does not present any problems, however, this is incorrect code. To fix this issue: - Suggestion: just reuse the first TSMutex in `ts_lua_http_intercept_process`, - NOT RECOMMENDED: ignore `ink_assert` because there is a `SCOPED_MUTEX_LOCK` for VIO mutex after `ink_assert`. The `ink_assert` statement is here to find this kind of problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
