A brief analysis of the count tracking of a request in nginx

First, let me explain the application method. There are two nginx modules, one named jtxy and the other named jtcmd. When an http request comes, it will enter the jtxy module for processing. jtxy will create a subrequest and send it to jtcmd. jtcmd will create an upstream flow to our upstream non-http service A for processing. After A completes the processing and gets the result, it will return the result to the jtcmd subrequest. The jtcmd subrequest returns the result to jtxy. This is the process. Let's track the count of a request.

1. A request arrives, a request is created, and count in ngx_http_alloc_request is initialized to 1

At this time, count is 1.

 r->main = r;
    r->count = 1;

2. When processing the request in the jtxy module, ngx_http_subrequest is called to create a subrequest, and the count is increased by 1 in ngx_http_subrequest.

At this time, count is 2

 r->main->count++;

3. When leaving a module (here is the jtxy module), ngx_http_finalize_request will be called, and the count will be reduced by one in ngx_http_finalize_request.

At this time, count is 1.

 if (r->content_handler) {
        r->write_event_handler = ngx_http_request_empty_handler;
        ngx_http_finalize_request(r, r->content_handler(r));
        return NGX_OK;
    }

4. Then we enter our sub-request jtcmd module. In this module, if we find that we are a sub-request ((r!=r->main)), we should increase the main request count by one. This point is highlighted in red because if 1 is not added, there will be a problem with the main request count. We will find this problem later when we continue to track the count minus 1.

Here is a jtcmd subrequest initiated by jtxy. The r and r->main here are not the same. r is jtcmd, and r->main is jtxy.

At this time, count is 2.

At the same time, because upstream is used in our subrequest jtcmd module, count needs to be increased by 1, but when we use ngx_http_read_client_request_body(r, ngx_http_upstream_init), ngx_http_read_client_request_body has already increased by 1, so we don't have to do this increase by 1 here.

At this time, count is 3.

You can take a look at Section 5.1.5 of "In-depth Understanding of nginx". There is an explanation for the need to add 1 to the upstream flow.

So, the count here is added twice.

 r->upstream->resolved->sockaddr = (struct sockaddr*)&backendSockAddr;
    r->upstream->resolved->socklen = sizeof(struct sockaddr_in);
    r->upstream->resolved->naddrs = 1;
 
    r->upstream->create_request = jtcmd_upstream_create_request;
    r->upstream->process_header = jtcmd_upstream_process_header;
    r->upstream->finalize_request = jtcmd_upstream_finalize_request;
    r->upstream->abort_request = jtcmd_upstream_abort_request;
 
    r->upstream->input_filter_init = ngx_http_jtcmd_filter_init;
    r->upstream->input_filter = ngx_http_jtcmd_filter;
    r->upstream->input_filter_ctx = jtcmdctx;
    
    //r->subrequest_in_memory = 1;
    
    if(r!=r->main) 
    {
        r->main->count++;
    }
 
    ngx_int_t rc = ngx_http_read_client_request_body(r, ngx_http_upstream_init);
    if (rc == NGX_ERROR || rc > NGX_OK) {
        return rc;
    }

Here r is the subrequest and r->main is the main request. Also note that the subrequest count is always 0.

 ngx_int_t
ngx_http_read_client_request_body(ngx_http_request_t *r,
    ngx_http_client_body_handler_pt post_handler)
{
    size_t preread;
    ssize_t size;
    ngx_int_t rc;
    ngx_buf_t *b;
    ngx_chain_t out;
    ngx_http_request_body_t *rb;
    ngx_http_core_loc_conf_t *clcf;
 
    r->main->count++;

5. As in step 3, after the request is processed, ngx_http_finalize_request will be called to reduce the count by one. However, the difference here is that this is a subrequest, and there is a step r = r->main; so the actual reduction is to the main request. This is also the reason why we added 1 as explained in red in step 4.

At this time, count is 2

 static void
ngx_http_close_request(ngx_http_request_t *r, ngx_int_t rc)
{
    ngx_connection_t *c;
 
    r = r->main;
    c = r->connection;
 
    ngx_log_debug2(NGX_LOG_DEBUG_HTTP, c->log, 0,
                   "http request count:%d blk:%d", r->count, r->blocked);
 
    if (r->count == 0) {
        ngx_log_error(NGX_LOG_ALERT, c->log, 0, "http request count is zero");
    }
 
    r->count--;

6. Then, because the subrequest uses upstream, count is increased by 1 for this reason, so when the upstream ends, it is reduced by 1.

At this time, count is 1.

7. After the child request is completed, the callback method of the parent request will continue to process, and then return to the main request module jtxy. Here, after the processing is completed, ngx_http_finalize_request will be called to end the request. At this time, count is 1 and the request will be released.

 void
ngx_http_free_request(ngx_http_request_t *r, ngx_int_t rc)
{
    ngx_log_t *log;
    ngx_pool_t *pool;
    struct linger linger;
    ngx_http_cleanup_t *cln;
    ngx_http_log_ctx_t *ctx;
    ngx_http_core_loc_conf_t *clcf;
 
    log = r->connection->log;
 
    ngx_log_debug0(NGX_LOG_DEBUG_HTTP, log, 0, "http close request");
 
    if (r->pool == NULL) {
        ngx_log_error(NGX_LOG_ALERT, log, 0, "http request already closed");
        return;
    }

Summarize

This is the end of this article about the count tracking of a request in nginx. For more information about the count tracking of nginx requests, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!