Hello!
I believe I found a bug in ngx_http_file_cache_exists(). I have looked at 1.4.1 and 1.5.7, it looks the same. I submit for your consideration:
When a node is not found in the cache and the attempt to allocate a new node fails, then a call is made to ngx_http_file_cache_forced_expire(). However, the cache is unlocked at this point, allowing for another worker processing a second request for the same object to lock the cache, get NULL from ngx_http_file_cache_lookup(), and thus allocate memory for a new node. The result is two nodes allocated and stored in the rbtree for the same file.
To fix this, I believe after re-locking after the call to ngx_http_file_cache_forced_expire(), we must again call ngx_http_file_cache_lookup() to decide if we need to allocate a new node or not.
Thank you.
Graham McCullough
Senior Software Engineer
Internap Network Services
I believe I found a bug in ngx_http_file_cache_exists(). I have looked at 1.4.1 and 1.5.7, it looks the same. I submit for your consideration:
When a node is not found in the cache and the attempt to allocate a new node fails, then a call is made to ngx_http_file_cache_forced_expire(). However, the cache is unlocked at this point, allowing for another worker processing a second request for the same object to lock the cache, get NULL from ngx_http_file_cache_lookup(), and thus allocate memory for a new node. The result is two nodes allocated and stored in the rbtree for the same file.
To fix this, I believe after re-locking after the call to ngx_http_file_cache_forced_expire(), we must again call ngx_http_file_cache_lookup() to decide if we need to allocate a new node or not.
Thank you.
Graham McCullough
Senior Software Engineer
Internap Network Services