Issue with 3rd-party memc and eval modules
agentzh at gmail.com
Wed Feb 17 15:26:28 MSK 2010
On Wed, Feb 17, 2010 at 7:07 PM, Valery Kholodkov
<valery+nginxen at grid.net.ru> wrote:
> In particular I don't like the presence of "eval_subrequest_in_memory" directive at all, because it specifies which way of internal communication the module needs to use, which doesn't make any sense for end user.
Thanks for replying to my pull request (although indirectly). Yeah, I
don't like the name of that directive as well. I chose that just
because I can't find a better name at that moment :P
> Second, the contributed code allocates a buffer and uses it in order to assemble the output of subrequest in it. This allocation can be totally avoided, if an appropriate state machine is implemented.
I just copied (almost) the way that ngx_http_upstream does buffered
outputing ;) To be honest, I didn't and don't see how that allocation
can be totally avoided for general use cases. Silly me! :P
> As soon as these issues are resolved, I'll accept this code.
It'll be great if you provide some more elaborate suggestions or even
patches to my patches if you do have the tuits :)
Just as Piotr mentioned ealier, the initial motivation for my ngx_eval
branch is to provide support for ngx_drizzle + ngx_rds_json. Adding
subrequest-in-memory support to every content handler/upstream handler
*with* output filter support is boring and no fun. So I chose to fix
ngx_eval rather than my content handler/upstream modules ;)
More information about the nginx