Backgroundrb devel - Apr 2008 - does backgroundrb server need rails environment?

Hi everyone,

I noticed that script/backgroudrb requires config/environment which
causes the backgroundrb server as well as the log worker to
''bloat'' to
35MB each. I am kind of sensitive to memory issues, so I patched the
code and essentially moved the require of environment from
script/backgroundrb to the meta_worker. Everything seems good and now
both backgroundrb server and log worker hang around 12MB.

Is there a reason why script/backgroundrb loads the environment? I
suppose it makes spawning rail workers faster?

Anyways, if anyone is interested, I can post my simple patch.
Paul

On Fri, 2008-04-11 at 15:15 -0700, Paul Kmiec wrote:
> Hi everyone,
> 
> I noticed that script/backgroudrb requires config/environment which
> causes the backgroundrb server as well as the log worker to
''bloat'' to
> 35MB each. I am kind of sensitive to memory issues, so I patched the
> code and essentially moved the require of environment from
> script/backgroundrb to the meta_worker. Everything seems good and now
> both backgroundrb server and log worker hang around 12MB.
> 
> Is there a reason why script/backgroundrb loads the environment? I
> suppose it makes spawning rail workers faster?
> 
> Anyways, if anyone is interested, I can post my simple patch.
> Paul
Environment loading is a little messy right now. I wanted to work on it
and make it clean, so i will welcome any patch.

Hi,

Attached are the changes that prevent backgroundrb server from loading
the rail''s boot & environment.

Removing environment has the implication that MasterProxy does not
load_rails_env ... therefore, the lazy load flag (if needed as a
feature) needs to be moved into meta_worker''s load_rails_env.

After removing environment, I noticed that we still needed
active_support. I was able to identify and fix the two issues caused
by not having active_support,
- find_reloadable_worker used classify ... turns out packet has its
own version of classify in Packet::NbioHelper which I was able to use.
- MissingSourceFile is defined in active support. The usages of
MissingSourceFile in backgroundrb & packet are the same as LoadError.
I just defined MissingSourceFile.

I think packet''s use of MissingSourceFile is a bug ... packet requires
all the libraries it needs in packet.rb, but does not include
active_resource. Also, since they have implemented their own version
of classify, I think this further supports their intent not to rely on
active_support. What do you think?

Also, I added yield to MasterProxy which allows additional custom
initialization, which I happen to do :).
Paul

On Fri, Apr 11, 2008 at 4:15 PM, hemant kumar <gethemant at gmail.com>
wrote:
>
>
>  On Fri, 2008-04-11 at 15:15 -0700, Paul Kmiec wrote:
>  > Hi everyone,
>  >
>  > I noticed that script/backgroudrb requires config/environment which
>  > causes the backgroundrb server as well as the log worker to
''bloat'' to
>  > 35MB each. I am kind of sensitive to memory issues, so I patched the
>  > code and essentially moved the require of environment from
>  > script/backgroundrb to the meta_worker. Everything seems good and now
>  > both backgroundrb server and log worker hang around 12MB.
>  >
>  > Is there a reason why script/backgroundrb loads the environment? I
>  > suppose it makes spawning rail workers faster?
>  >
>  > Anyways, if anyone is interested, I can post my simple patch.
>  > Paul
>
>  Environment loading is a little messy right now. I wanted to work on it
>  and make it clean, so i will welcome any patch.
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backgroundrb.diff
Type: application/octet-stream
Size: 4423 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080412/5d7e95db/attachment-0001.obj

On Sat, 2008-04-12 at 17:45 -0700, Paul Kmiec wrote:
> Hi,
> 
> Attached are the changes that prevent backgroundrb server from loading
> the rail''s boot & environment.
> 
> Removing environment has the implication that MasterProxy does not
> load_rails_env ... therefore, the lazy load flag (if needed as a
> feature) needs to be moved into meta_worker''s load_rails_env.
So, if users who want to pass AR objects from rails, they will be in
trouble because of no environment loading at all. I think we do need an
option like ''master_rails_env'' enable or disable.
> 
> After removing environment, I noticed that we still needed
> active_support. I was able to identify and fix the two issues caused
> by not having active_support,
> - find_reloadable_worker used classify ... turns out packet has its
> own version of classify in Packet::NbioHelper which I was able to use.
> - MissingSourceFile is defined in active support. The usages of
> MissingSourceFile in backgroundrb & packet are the same as LoadError.
> I just defined MissingSourceFile.
> 
> I think packet''s use of MissingSourceFile is a bug ... packet
requires
> all the libraries it needs in packet.rb, but does not include
> active_resource. Also, since they have implemented their own version
> of classify, I think this further supports their intent not to rely on
> active_support. What do you think?
Yes, thats a bug in packet. I have made those changes. Anyone interested
in hacking packet itself can start here (I am looking at you Brian
too) :

http://github.com/gnufied/packet/tree/master


> 
> Also, I added yield to MasterProxy which allows additional custom
> initialization, which I happen to do :).
> Paul
Hmm, thats nice. I will get this patch in.