From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 24 Apr 2018 18:35:59 +0300 From: Vladimir Davydov Subject: Re: [PATCH v2 1/4] iproto: fix error with input discarding Message-ID: <20180424153559.7yivt4gmjzmb4z4l@esperanza> References: <4557a526b2dca93a82749a50475338dd7990af6f.1524502856.git.v.shpilevoy@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4557a526b2dca93a82749a50475338dd7990af6f.1524502856.git.v.shpilevoy@tarantool.org> To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org List-ID: On Mon, Apr 23, 2018 at 08:05:01PM +0300, Vladislav Shpilevoy wrote: > Long-polling request has a feature allowing to discard an input > buffer in a connection before the main request is finished. > > Before the patch discard just calls iproto_resume() trying to > notify libev, that is can get new data. But is makes no sense, > because iproto_resume() continues only connections stopped due > to reached limit of maximal requests in fly, but not connections > whose buffer is overflowed. Such stopped connections can be > continued only after a request is complete. > > To continue read from the connection whose buffer was freed by > discarding long-poll it is necessary to explicitly feed to it > EV_READ event. On this event iproto_connection_on_input will read > a blocked data if it exists. > --- > src/box/iproto.cc | 5 +- > test/box/request_limit.result | 122 ++++++++++++++++++++++++++++++++++++++++ > test/box/request_limit.test.lua | 70 +++++++++++++++++++++++ > 3 files changed, 195 insertions(+), 2 deletions(-) > create mode 100644 test/box/request_limit.result > create mode 100644 test/box/request_limit.test.lua Ack