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... > > -- 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 _______________________________________________ Monkey mailing list [email protected] http://lists.monkey-project.com/listinfo/monkey
