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/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel