Thrift proxy code contribution

[Maxim Dounin]

Hello!

On Tue, Jul 07, 2020 at 02:45:00PM +0000, 魏俊杰 Junjie Wei wrote:

> Hi Maxim Dounin, I'm glad to receive your reply.
> 
> The nginx directories are as follow:
> 
> auto
> conf
> contrib
> docs
> misc
> objs
> src
> |-core
> |-event
> |-http
> |-mail
> |-misc
> |-os
> |-stream
> |-thrift
>   |-modules
> 
> 
> 
> Just like supporting tcp proxy, we developed a series of modules 
> to support thrift protocol proxying.
> 
> No matter using or compiling, these modules are optional.
> 
> 
> Config example:
> 
> worker_rlimit_nofile 204800;
> worker_processes 1;?
> error_log  logs/error.log error;
> pid        run/nginx.pid;
> http{
>     ...
> }
> thrift {
>     access_log logs/access.log;
> 
>     server {
>         listen 8000;
>         server_name counter; # counter is service name in thrift 
>         request
>         location ping {      # ping is method name in thrift 
>         request
>             proxy_pass ua;
>  ?       }
>     }
> 
>     upstream ua {
>         server 127.0.0.1:8003;
>     }
> }?
> 
> 
> Most of our codes are placed in thrift directory, which consists 
> of 1 core module:
> 
>   1.  ngx_thrift_core_module
> 
> and other functional modules:
> 
>   1.  ngx_thrift_upstream_module
> 
>   2.  ngx_thrift_proxy_module
>   3.  ngx_thrift_log_module
>   4.  ngx_thrift_upstream_check_module：tcp active health check
>   5.  ngx_thrift_upstream_keepalive_module
>   6.  ngx_http_dynamic_upstream_module : using http request to 
>   change nginx upstream endpoint without reload nginx conf
>   7.  ngx_thrift_limit_req_module
>   8.  ngx_thrift_dynamic_req_module: dispatching request to 
>   different upstream accoding to request content
> 
> The only things we change in original nginx are:
> 
>   1.  build script in auto directory to support compile thrift 
>   proxy core framework code into nginx
>   2.  macro constance like "#define NGX_LOG_DEBUG_THRIFT 0x800" 
>   in ngx_log.h, which is non-logical
> 
> Otherwise, we developed a standalone thrift procotol 
> encoder/decoder and we preliminarily plan to publish it 
> independently, which will be imported in nginx as a third party 
> lib.
> 
> Do you think out thoughts are feasible? We are really looking 
> forward for suggestions and opinions.

I don't see any problems with publishing your code as a module for 
nginx.  Changes you've mentioned in nginx itself should be 
relatively easy to avoid.

> By the way, must out codes support other OS like Windows or 
> other event mechanics like poll, select, kqueue?

That's completely up to you.  If you don't, it might be a good 
idea to outline somewhere in the documentation that your module 
has known bugs and cannot be used with some event methods.

-- 
Maxim Dounin
http://mdounin.ru/