[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: Problems using Apache::Reload
From:       Jonathan Vanasco <jvanasco () 2xlp ! com>
Date:       2007-06-30 15:55:12
Message-ID: 03AE2161-DD72-4E32-B2DE-55CC9D025718 () 2xlp ! com
[Download RAW message or body]


On Jun 30, 2007, at 2:40 AM, Tony van der Hoff wrote:
>
> Well, it is my intention that the modules should be reloaded if  
> they've
> changed; that's the whole point of using Apache::Reload, so I'm  
> pleased it
> works. Presumably, if they haven't changed, the only performance  
> hit is a
> stat to the file system, and then only on those modules which  
> explicitly
> call Apache::Reload. I think I can live with that :)

Thats the intention of the devel environment.  But aside from the  
performance hit, reload doesn't work perfectly.  some module changes  
won't get picked up due to class override / superclass conflicts,  
other changes will cause Reload to just crash your server.  when  
you're running reload, you're ideally having the stat and a clean  
reload -- in practice you can get larger performance hits from the  
stat being read wrong and tons of crashes.

> However, without the ability to restart the server, and short of  
> renaming
> the files, how should I update my software? It won't happen much at  
> the
> production end, but it will certainly happen. Shouting Never,  
> Never, Never
> is all very well, and undoubtedly good advice, but it's a bit  
> impractical
> without an alternative.

assuming you're on a nix/bsd -- you need to be able to restart the  
server.  if you can't , then you shouldn't be using mod_perl.   see  
if you can run apache on a port you can control, then proxypass to it.
mod_perl does a lot of performance/memory optimizations by using the  
copy-on-write model for vars and caching compiled subs.  when you  
'reload' code, you're just redefining the subs... which means they  
get unshared.

illustration
	start 	parent-a
	fork		child-a child-a child-a
	update code
	reload
			child-a child-a child-b
			child-a child-b child-b
			child-b child-b child-b
	i'm not sure how reload affects the master-process memory--  but I  
have a funny feeling that new children will spawn with the pre-update  
code, then stat to the new  code



> What are the other problems you refer to? I've been lurking on this  
> list for
> some months, but have not seen anything mentioned, and Google  
> doesn't throw
> up anything on the first few pages.

look back within the past 18-6 months.  there was a lot of reload  
talk then.  not as much lately.

also, you should never do an apachectl restart/graceful.
you want to do a full apache stop,  and then apache  start.  the  
integrated restart command will essentially cause a memory leak ( its  
not really leaking, but the memory isn't recycled/overwrriten -- so  
your process will double on size the first restart, etc etc etc )



On Jun 30, 2007, at 6:13 AM, Clinton Gormley wrote:
> With regards using Apache::Reload in production, my understanding is
> that, while Apache::Reload is really useful for development, there are
> edge cases where things get messed up, and which require a stop- 
> start to
> get them working again.  And for this reason, we would not usually
> consider using this module in production.

its much less edge-cases than it is use-cases.



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|   CEO/Founder SyndiClick Networks
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|     Founder/CTO/CVO
|      FindMeOn.com - The cure for Multiple Web Personality Disorder
|      Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -
|      RoadSound.com - Tools For Bands, Stuff For Fans
|      Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - - - - -


[prev in list] [next in list] [prev in thread] [next in thread]