From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.64.68.5 with SMTP id r5csp443132iet; Tue, 7 Aug 2012 03:49:40 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncCKGMsZCuHxDD5YOBBRoEnM2MfA@googlegroups.com designates 10.180.105.163 as permitted sender) client-ip=10.180.105.163 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncCKGMsZCuHxDD5YOBBRoEnM2MfA@googlegroups.com designates 10.180.105.163 as permitted sender) smtp.mail=rack-devel+bncCKGMsZCuHxDD5YOBBRoEnM2MfA@googlegroups.com; dkim=pass header.i=rack-devel+bncCKGMsZCuHxDD5YOBBRoEnM2MfA@googlegroups.com Received: from mr.google.com ([10.180.105.163]) by 10.180.105.163 with SMTP id gn3mr5672296wib.0.1344336579793 (num_hops = 1); Tue, 07 Aug 2012 03:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe:content-type; bh=Kup2Klc9BfCwaOr8zfkDpJfwAK/oNZzJNzVURNYS5lE=; b=O0EJcKXNk0it3AriPEK9bMtNWoesWL5eKw2oNlnR1iWyQUqEZEjOTVpfND2SnpQoVB 0fSvmtSjfJogV9bNRAd0pLWlakuA+ue1EGm/y2AG46DFpd+EYWe/ZSTKKqpS1pcd1xFx qEpFVPHaPFkD6iVH2GU4u5PMYA+SlErx7Bn94= Received: by 10.180.105.163 with SMTP id gn3mr888491wib.0.1344336579736; Tue, 07 Aug 2012 03:49:39 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.180.82.231 with SMTP id l7ls1282544wiy.4.canary; Tue, 07 Aug 2012 03:49:38 -0700 (PDT) Received: by 10.180.96.42 with SMTP id dp10mr1689862wib.2.1344336578900; Tue, 07 Aug 2012 03:49:38 -0700 (PDT) Received: by 10.180.96.42 with SMTP id dp10mr1689861wib.2.1344336578870; Tue, 07 Aug 2012 03:49:38 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by gmr-mx.google.com with ESMTPS id fb20si2489628wid.3.2012.08.07.03.49.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Aug 2012 03:49:38 -0700 (PDT) Received-SPF: pass (google.com: domain of ghazel@gmail.com designates 209.85.212.173 as permitted sender) client-ip=209.85.212.173; Received: by wibhm6 with SMTP id hm6so2162998wib.2 for ; Tue, 07 Aug 2012 03:49:38 -0700 (PDT) Received: by 10.217.1.195 with SMTP id n45mr6614593wes.179.1344336578520; Tue, 07 Aug 2012 03:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.24.1 with HTTP; Tue, 7 Aug 2012 03:49:18 -0700 (PDT) In-Reply-To: References: <2cac8438-1819-4887-bce9-9a99578539db@f31g2000pri.googlegroups.com> From: ghazel@gmail.com Date: Tue, 7 Aug 2012 03:49:18 -0700 Message-ID: Subject: Re: Middleware and post-request processing To: rack-devel@googlegroups.com X-Original-Sender: ghazel@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ghazel@gmail.com designates 209.85.212.173 as permitted sender) smtp.mail=ghazel@gmail.com; dkim=pass header.i=@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=20cf301fbe3738a57304c6aac033 --20cf301fbe3738a57304c6aac033 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 7, 2011 at 10:20 AM, James Tucker wrote: > > On Jun 3, 2011, at 4:23 PM, ghazel wrote: > > > It seems to me that Rack is in need of a new post-response stage of > > processing. This stage would occur after the response is fully written > > and the client is unblocked, and before the next request is processed. > > > > Similar to what OobGC ( > http://bogomips.org/unicorn.git/tree/lib/unicorn/oob_gc.rb#n59 > > ) accomplishes, it is sometimes useful to perform additional > > operations after the response is written without blocking the client. > > For example, the Oink middleware logs statistics about the request, > > but blocks the response since it has no ability not to: ( > > > https://github.com/noahd1/oink/blob/4158d71bc9150f011072b2c6eefe73c720a78d46/lib/oink/middleware.rb#L16 > > ). This processing takes time, and needlessly delays the response. > > > > This proposal would entail something like a single function which is > > called on each middleware after the response is written to the client > > and the socket is closed (depending on the server implementation). For > > servers which have no ability to not block the client or delay further > > requests the function should still be called, and the impact would be > > similar to the behavior today. > > > > Thoughts? > > > The problem is, this isn't simple. Different servers have different > scheduling mechanisms, and deferred operations specifications reach into > scheduling in a horrible way. > > Should these run linearly? Should they be able to be pooled if > env['rack.multithreaded']. In that case should they receive the same number > of workers as the main request/response pool? Should they work out of the > same pool? > > And that's just some basics with threads... > > Ideally, the callback would be issued from the same process / thread / fiber / context as the request itself. So all the questions of parallelization are answered exactly like you would for requests. I'd be interested to know of a server where this is not possible. > You can quite easily handle this on your own in middleware or servers a > number of ways today, without introducing either far reaching / extensive > specs or incomplete restrictions that parallel some we already have (like > stack based control). How can this be quite easily handled today? Many plugins and frameworks do not manage to do it when they should. -Greg --20cf301fbe3738a57304c6aac033 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2011 at 10:20 AM, James Tucker <jftucker@gmail.com>= wrote:

On Jun 3, 2011, at 4:23 PM, ghazel wrote:

> It seems to me that Rack is in need of a new post-response stage of > processing. This stage would occur after the response is fully written=
> and the client is unblocked, and before the next request is processed.=
>
> Similar to what OobGC ( http://bogomips.org/unicorn.= git/tree/lib/unicorn/oob_gc.rb#n59
> ) accomplishes, it is sometimes useful to perform additional
> operations after the response is written without blocking the client.<= br> > For example, the Oink middleware logs statistics about the request, > but blocks the response since it has no ability not to: (
> https://git= hub.com/noahd1/oink/blob/4158d71bc9150f011072b2c6eefe73c720a78d46/lib/oink/= middleware.rb#L16
> ). This processing takes time, and needlessly delays the response.
>
> This proposal would entail something like a single function which is > called on each middleware after the response is written to the client<= br> > and the socket is closed (depending on the server implementation). For=
> servers which have no ability to not block the client or delay further=
> requests the function should still be called, and the impact would be<= br> > similar to the behavior today.
>
> Thoughts?


The problem is, this isn't simple. Different servers have d= ifferent scheduling mechanisms, and deferred operations specifications reac= h into scheduling in a horrible way.

Should these run linearly? Should they be able to be pooled if env['rac= k.multithreaded']. In that case should they receive the same number of = workers as the main request/response pool? Should they work out of the same= pool?

And that's just some basics with threads...


Ideally, the callback would be issued = from the same process / thread / fiber / context as the request itself. So = all the questions of parallelization are answered exactly like you would fo= r requests. I'd be interested to know of a server where this is not pos= sible.
=C2=A0
You can quite easily handle this on your own in middleware or servers a num= ber of ways today, without introducing either far reaching / extensive spec= s or incomplete restrictions that parallel some we already have (like stack= based control).

How can this be quite easily handled today? Many plugins and= frameworks do not manage to do it when they should.

-Greg

--20cf301fbe3738a57304c6aac033--