//when subrequests is 0?
if (r->main->subrequests == 0) {
ngx_log_error(NGX_LOG_ERR, r->connection->log, 0,
“subrequests cycle while processing "%V"”, uri);
r->main->subrequests = 1;
return NGX_ERROR;
}
…
//why subrequests need plus plus?
r->main->subrequests++;
*psr = sr;
return ngx_http_post_request(sr);
}
the problem is after call ngx_http_subrequest and r->main->subrequests
will
not change（because subrequests-- and then ++), so when subrequests is
0？
I think if r->main->subrequests is the max subrequests number,
r->main->subrequests++
need to be removed.
if r->main->subrequests is avoid subrequests cycle, so why need
r->main->subrequests++
? because i think r->main->subrequests-- and judge r->main->subrequests
is
or not 0 can avoid subrequests cycle.
On Thu, Jul 01, 2010 at 08:08:42PM +0800, BoBo wrote:
ngx_connection_t *c;
"subrequests cycle while processing \"%V\"", uri);
return ngx_http_post_request(sr);
}
the problem is after call ngx_http_subrequest and r->main->subrequests will
not change（because subrequests-- and then ++), so when subrequests is 0？
Right now - it would never be 0 (and this strikes badly as long as
you issue > 255 subrequests, as r->main->counter overflows). This
logic was introduced for older subrequest implementation where
subrequests were completed directly. Subrequest processing was
changed in 0.7.25 and this subrequests-- and subrequests++ no
longer make sense.
I’ve posted a patch a while ago which moves r->main->subrequests++
into request finalization, see here (in Russian):
On Fri, Jul 02, 2010 at 11:03:20AM +0800, BoBo wrote:
thanks , but now nginx use what to avoid subrequests cycle?
I think your patch doesn’t avoid subrequests cycle, because the certain may
call ngx_http_subrequest again finalize request（the newest subrequest), and
then cause subrequests cycle.
so i think should remove r->main->subrequests++.
Removing r->main->subrequests++ completely will limit total number
of subrequests to NGX_HTTP_MAX_SUBREQUESTS. This isn’t intended
(and will cause problems in many configurations, e.g. in the thread
I linked it exceeded 255 without any loops).
Limit on number of subrequests was always meant to limit number of
simulteneously executing subrequests, and this is what currently
causes problems (due to r->main->count overflow and resulting
SIGSEGV).
In general, I see three options on how to handle this:
Resurrect r->main->subrequests limit as in patch linked.
Drop r->main->subrequests limit and check for r->main->count
overflows intead.
Drop r->main->subrequests limit and introduce something like
subrequest recursion counter to limit depth of subrequests, not
it’s count. This implies (2) or bumping r->main->count to
some bigger datatype to avoid overflows.
thanks , but now nginx use what to avoid subrequests cycle?
I think your patch doesn’t avoid subrequests cycle, because the certain
may
call ngx_http_subrequest again finalize request（the newest subrequest),
and
then cause subrequests cycle.