#2105 closed defect (wontfix)
thread_pools with variable $server_name
| Reported by: | Carlos | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-core | Version: | 1.19.x | 
| Keywords: | Cc: | ||
| uname -a: | Linux nginx1 5.4.0-54-generic #60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: | 
          nginx version: nginx/1.19.5
           built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2) built with OpenSSL 1.1.1f 31 Mar 2020 (running with OpenSSL 1.1.1g 21 Apr 2020) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.5/debian/debuild-base/nginx-1.19.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'  | 
      ||
Description
The context:
thread_pool $server_name threads=12;
http {
    server {
        aio threads=$server_name;
    }
}
This setup produces no errors at config test nginx -t but HTTP produces Error 500 and at error.log because thread_pool is not found.
thread pool "example.com" not found, server: example.com, request: "GET / HTTP/1.1"
It should either be allowed, or produce an an error at config test like nginx.conf: $server_name is not allowed here.
Change History (4)
comment:1 by , 5 years ago
| Resolution: | → wontfix | 
|---|---|
| Status: | new → closed | 
comment:2 by , 5 years ago
My use case here would be to generate a single thread_pool per server_name dynamically at server restart/reload; regarding your comments, this can't be done.
Each thread_pool must be defined manually at main context and then it can be accessed with aio threads=$server_name at server context?
I understand your point, so if this is not a bug (or lack of documentation) feel free to close it.
comment:3 by , 5 years ago
Thread pools are global objects and must be explicitly defined. There is no special magic way to ask nginx to define a thread pool for each server in the configuration. And if such a magic way will be ever introduced, certainly this won't be a $server_name in the thread pool name, as the thread_pool directive defines just one thread pool.

The thread_pool directive do not support variables. Rather, it defines a global object, a thread pool, with a particular name given,
$server_namein your case. Note that variables are meaningless when defining global objects like thread pools.Note well that if variables are supported in a particular configuration directive, this is explicitly documented. If there is no relevant clause in the documentation, like in the
thread_poolcase, this means variables cannot be used in a particular configuration directive. If the syntax of a particular directive permits an arbitrary string, the$character will be simply interpreted as is.In contrast, the aio directive supports variables, and this is explicitly documented:
Accordingly, your configuration tries to use the
example.comthread pool, which is not defined by your configuration (the only thread pool defined by the configuration is$server_name). Further, it is not possible to tell if the pool is defined or not during configuration parsing, as the pool name uses variables and hence is only known during processing of a request.That is, the configuration is syntactically correct, hence
nginx -tsucceeds. Yet it is practically useless, as all requests will result in errors.While nginx generally tries hard to fail non-working configurations during configuration testing, this is unfortunately not possible when variables are used and the fact of the error is only known when evaluating requests. The general recommendation is to avoid using variables when they are not needed, and thoroughly test configurations if variables are using.
A possible solution for this particular case might be to restrict
thread_poolsyntax to do not allow the$character. This, however, looks like generally unneeded limitation, especially keeping in mind that variable anyway are meaningless in names of global objects like thread pools.