On Fri, Aug 03, 2012 at 01:19:37AM -0600, Eduardo Silva wrote: > On Tue, Jul 31, 2012 at 4:24 AM, Sonny Karlsson <[email protected]> wrote: > > Hi > > > > I've found the issue causing tcp nodelay to fail on some connections > > in my fastcgi plugin. The issue is unrelated tho the flag itself. > > > > If _mkp_event_read is called on a plugin created connection and > > returns MK_PLUGIN_RET_EVENT_CONTINUE while there is still data to be > > read (no 0 or -1 returned from call). The mk_conn_read function will > > check if a http session exists on this thread and create one if it > > does not. Because my connection is a unix socket, I get the tcp > > nodelay warning and a timeout on request because the epoll event is > > changed. > > > > Is this expected behavior? Should not MK_PLUGIN_RET_EVENT_CONTINUE > > allow the event to stay inside the module? Current behavior is the > > same as if I'd return MK_PLUGIN_RET_EVENT_CONTINUE. > > > > The issue is resolved in the plugin by always returning > > MK_PLUGIN_RET_EVENT_OWNED. > > - since your latest patches TCP_NODELAY is not longer in place, do you > still face the same issue ? > - MK_PLUGIN_RET_EVENT_CONTINUE means: this event is not mine, > returning the control to the caller...when you return the *OWNED > version it means that you take care of it and nobody else. > > please confirm if still a problem... >
It's no longer an issue. The problem was my understanding of what MK_PLUGIN_RET_EVENT_CONTINUE was meant to do, and I changed the code since. Thanks for clarifying! > > > > -- Sonny Karlsson > > _______________________________________________ > > Monkey mailing list > > [email protected] > > http://lists.monkey-project.com/listinfo/monkey > > > > -- > Eduardo Silva > http://edsiper.linuxchile.cl > http://www.monkey-project.com -- Sonny Karlsson _______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
