07:30 <tsal> hey all, is there any good documentation on how to best-practice middleware stuff ?

07:30 <tsal> I think i found a bug, that files opened in a constructor of an instance of a middleware, are (under passenger) owned by root

07:31 <tsal> and, I was once told here that having middlewares that are instantiated, and have instance methods is almost always a bad idea

07:43 <cypher23> tsal, apache/passenger wouldn't happen to run as root, would it?

07:44 <tsal> no, but it's started by root - then should switch to `www-data` in our environment

07:44 <cypher23> hm.

07:44 <tsal> if the file handle is opened in an instance method, something that runs when the first request lands, then the file is owned by `www-data` as we expect

07:44 <raggi> here's the thing

07:45 <raggi> rack dosn't instance your middlewares for you

07:45 <raggi> it also as such, doesn't result in any cleanup

07:46 <raggi> so, if you do, say, def initialize; @var = 'a' * 8.megabytes; end, then, that won't get cleared up

07:46 <raggi> more to the point

07:46 <tsal> I see

07:46 <raggi> def call; @var = 'a' * 8.megabytes; end

07:46 <tsal> I see

07:46 <raggi> that's more interesting, because although @var is replaced every request, the idle ram usage includes instance data from the last request

07:47 <tsal> soooo, that's good to know

07:47 <raggi> a common pattern to deal wiht this is

07:47 <raggi> def call; dup._call; end

07:47 <raggi> and then you can use ivars and they'll be thrown away after

07:47 <tsal> raggi: ok, I've seen that a lot - but I was told it was for thread safety

07:47 <raggi> poppycock

07:47 <tsal> (which didn't seem to make sense ^^ )

07:48 <raggi> it gives you atomicity wrt per request data for that middleware

07:48 <raggi> but that's no assurance of thread safety

07:48 <tsal> :)

07:48 <raggi> @@var, and it's over

07:48 <tsal> heh, sure thing

07:48 <raggi> um, wrt your other issue

07:48 <raggi> you're using REE i presume

07:48 <raggi> so it's in a forking configuration

07:49 <raggi> i'd expect what's happening, is that you're opening the handle during the boot of your app

07:49 <raggi> (before any requests are made)

07:49 <raggi> which may be running as root w/ passenger, i'm not certain of the detail there

07:49 <raggi> but i suspect it's something along those lines

07:49 <tsal> right, we're instantiating the middleware in environment.rb (the middleware needs external config) and that is also the method that opens the file handle

07:49 <tsal> and stores it in an instance variable

07:49 <raggi> if you lazy init on request, you'll get a correctly owned file

07:50 <raggi> other than that, lookup passenger doc details

07:50 <tsal> yeah, sure thing

07:50 <raggi> i think you can force the workers to run as a particular user

07:50 <tsal> thanks raggi

07:50 <tsal> that makes perfect sense

07:50 <tsal> (yeah, that's what we're doing, root process, and the rest as www-data)

07:50 <tsal> and, we figured that passenger was running the middlewares before it forked correctly

07:51 <raggi> it builds the stack yeah

07:51 <raggi> to get the most out of COW

07:51 <tsal> that, coupled with the idea that this was because we needed an instance, lead me to wonder if there was a better practice

07:51 <tsal> might I ask if there's a reason there's no GC for instance vars ?

07:51 <tsal> Ruby thing ?

07:51 <raggi> no

07:51 <raggi> you're referencing them from the middleware object

07:52 <raggi> and the middleware object is referenced by the middleware chain

07:52 <raggi> whcih is referenced by your rack server

07:52 <raggi> which is referenced by the top level of your application

07:52 <raggi> it's not a leak if you're still referencing it, it's a programmer error :)

07:52 <tsal> heh, sure

07:52 <tsal> :-D

07:55 <tsal> thanks raggi ^

10:23 <tsal> hey, raggi since i'm going to be hammered by the man that can here, what's the reason that the instances of the middleware (and thus, the instance vars) aren't going out of scope ?

10:26 <raggi> becuase the middleware doesn't

10:26 <raggi> use Middleware.new # this instance is in the stack forever

10:27 <tsal> sure, but then instance methods in there, should be recycled, right ?

10:27 <tsal> if each request is reassigning @file_handle, or something ?

10:27 <raggi> sure, i'm not saying they never get replaced

10:29 <tsal> ok, great, but they also never go out of scope

10:29 <raggi> the middleware object doesn't ever get dereferenced

10:29 <raggi> that's the point

10:30 <cypher23> tsal, you could do something like this: http://gist.github.com/329389

10:30 <tsal> sure, do by calling .dup, then you're making a scope that is dereferenced

10:30 <rutlov> Page title is: gist: 329389 - GitHub.

10:30 <cypher23> but that basically is the same as with dup._call

10:30 <tsal> nice cypher23

10:30 <tsal> that's a nice approach

10:31 <cypher23> tsal, but you still have the issue that anything you allocate on the class level will stay in memory for the whole lifetime of the server, if it's referenced

10:31 <tsal> thanks dudes

10:32 <tsal> I feel equipped to tackle that with the dude from work now :-D

10:32 <raggi> http://pastie.textmate.org/private/pqjuocfxuosts5pjsmfwa

10:32 <rutlov> Page title is: Private Paste - Pastie.

10:33 <raggi> http://pastie.textmate.org/private/qsyzbqe7nactiycojxyq

10:33 <rutlov> Page title is: Private Paste - Pastie.

10:34 <tsal> thanks raggi

10:36 <tsal> ok, interesting

10:37 <raggi> the latter will result in far less memory fragmentation