How to abort subrequest properly?

Marat Dakota dakota at
Wed Jul 3 20:40:31 UTC 2013

Yichun, thanks for your notes.
Even though they are not as optimistic as I would like them to be :).


On Thu, Jul 4, 2013 at 12:00 AM, Yichun Zhang (agentzh)
<agentzh at>wrote:

> Hello!
> On Wed, Jul 3, 2013 at 6:17 AM, Marat Dakota wrote:
> > Are there any adequately hardcore methods to close subrequest's
> connection?
> > I mean, what steps should be done internally?
> >
> I was also thinking hard about this problem when I was implementing
> the "light thread" model in our ngx_lua module.
> The subrequest mechanism does not know the details of the target
> location's handlers. The target location's handler may introduce
> multiple upstream connections. It's not safe at all to assume any
> thing here.
> A possible work-around here is to actively call the cleanup handlers
> registered by the subrequest. But unfortunately, the cleanup handlers
> are registered into the main request, it's not easy to distinguish a
> specific subrequest's cleanup handlers from others. Another challenge
> here is that the subrequest is sharing the same memory pool with its
> ancestors, so freeing up all the memory associated with the subrequest
> is not possible.
> To conclude, it's not easy to abort a pending subrequest without
> aborting the main request. And I also decide to throw out an error in
> my ngx_lua module when the user Lua code is trying to abort a "light
> thread" with a pending subrequest.
> > For now, I'm just setting a flag in subrequest's context and just
> ignoring
> > the data in subrequest's body filter depending on this flag. It is ok,
> but
> > if there is a relatively simple way to close the connection to avoid
> > meaningless data transfers and meaningless waits for subrequest to be
> > finished — it would be nice.
> >
> See above :)
> Best regards,
> -agentzh
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx-devel mailing list