How to abort subrequest properly?

[Marat Dakota]

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

--
Marat




On Thu, Jul 4, 2013 at 12:00 AM, Yichun Zhang (agentzh)
<agentzh at gmail.com>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 nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130704/7a01bdb9/attachment.html>