Re: Query on deletion of Request pool
On Wed, Mar 26, 2008 at 10:51 PM, Arnab Ganguly [EMAIL PROTECTED] wrote: In the particular box only Apache is running no other application process is running.Also one more observation was when the Apache is stopped the free -m doesn't result to the original memory restore.We have to reboot the box to restore the original RAM.Should I try using smaller value for MaxMemFree? Thanks and regards -A It sounds like you're tracking the wrong numbers if memory isn't free when the application terminates. -- Eric Covener [EMAIL PROTECTED]
Re: Query on deletion of Request pool
It sounds like you're tracking the wrong numbers if memory isn't free when the application terminates. Not clear to me.Can you please add some more lights to it. Thanks A On Thu, Mar 27, 2008 at 7:54 PM, Eric Covener [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 10:51 PM, Arnab Ganguly [EMAIL PROTECTED] wrote: In the particular box only Apache is running no other application process is running.Also one more observation was when the Apache is stopped the free -m doesn't result to the original memory restore.We have to reboot the box to restore the original RAM.Should I try using smaller value for MaxMemFree? Thanks and regards -A -- Eric Covener [EMAIL PROTECTED]
Re: Dynamic configuration for the hackathon?
On Wed 26 Mar 2008, Akins, Brian wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks like programming, but it's not designed as a programming language. Result: confused and frustrated users. This is what I had in mind when I suggested having Lua blocks of code. No need to invent a new language when a perfectly fine one exists... As Issac pointed out something similar can be done with Perl blocks at the cost of having mod_perl in core. Those are not evaluated evaluated per-request. But based on mod_perl there is Apache2::Translation that does per-request configuration. It hooks uri translation, maptostorage and fixup to do the job. Again it needs a perl interpreter in core and hence doesn't work well with threaded MPMs. So I was going to reimplement it based on mod_wombat some time this year. I just wanted to add these $0.02 to the discussion. Torsten
Re: Dynamic configuration for the hackathon?
I used to use mod_macro, then I moved to mod_perl but like you said. mod_perl is great (well, more okay than great) for dynamic configurations that change/get generated on start and not per request. A new more flexible alternative would be awsome. Jorge (on vacation) On Thu, Mar 27, 2008 at 8:58 AM, Torsten Foertsch [EMAIL PROTECTED] wrote: On Wed 26 Mar 2008, Akins, Brian wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks like programming, but it's not designed as a programming language. Result: confused and frustrated users. This is what I had in mind when I suggested having Lua blocks of code. No need to invent a new language when a perfectly fine one exists... As Issac pointed out something similar can be done with Perl blocks at the cost of having mod_perl in core. Those are not evaluated evaluated per-request. But based on mod_perl there is Apache2::Translation that does per-request configuration. It hooks uri translation, maptostorage and fixup to do the job. Again it needs a perl interpreter in core and hence doesn't work well with threaded MPMs. So I was going to reimplement it based on mod_wombat some time this year. I just wanted to add these $0.02 to the discussion. Torsten -- ~Jorge
Re: Dynamic configuration for the hackathon?
On Thu, 27 Mar 2008 08:17:01 -0400 Akins, Brian [EMAIL PROTECTED] wrote: On 3/27/08 3:58 AM, Torsten Foertsch [EMAIL PROTECTED] wrote: So I was going to reimplement it based on mod_wombat some time this year. The nice thing about lua, in addition to being lightweight, is that most of the url mapping/rewriting can be simple lua statements. Lua fixups if string.match(r.uri, '/something') then r.filename = '/www/that/path' end /Lua Fine for users who want to hack their own server. Like Perl. But r.filename is the kind of innards we really don't want to expose to the typical mod_rewrite user! And if the more complicated modules had a little lua glue: if string.match(r.uri, '/something') then mod_cache:cacheable( r ) end A fine recipe for users shooting themselves in the foot, PHP-style. How would you propose to make that work without hackage to existing modules? If one were so inclined, the entire configuration could be lua. Just define and register these functions that need to run per request. That'll go alongside DrBacchus's You can do everything with mod_rewrite :-) -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Proposal: a cron interface for httpd
On Wed, 26 Mar 2008 17:15:02 +0100 Rainer Jung [EMAIL PROTECTED] wrote: ap_hook_monitor? As I understand the monitor hook, httpd itself also uses it. Thus letting modules do maintenance stuff in the same hook could easily break the timing of the httpd internal tasks. There's nothing there whose timing is critical! For me at least that was the reason not to use the monitor hook for mod_jk idle connection checks. Doesn't mod_jk pre-date the monitor hook? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Proposal: a cron interface for httpd
Nick Kew wrote: On Wed, 26 Mar 2008 17:15:02 +0100 Rainer Jung [EMAIL PROTECTED] wrote: ap_hook_monitor? As I understand the monitor hook, httpd itself also uses it. Thus letting modules do maintenance stuff in the same hook could easily break the timing of the httpd internal tasks. There's nothing there whose timing is critical! Good to know. For me at least that was the reason not to use the monitor hook for mod_jk idle connection checks. Doesn't mod_jk pre-date the monitor hook? Yes, but the maintenance method in mod_jk, responsible for regular cleanup stuff not directly related to single requests wasn't there from the beginning. At least I remember that I found the monitor hook, when I was looking for a nice way to do it, but decided against using it, because I wasn't sure about negative implications for httpd itself, if running the hook would have taken longer than expected. Of course mod_jk also works for httpd 1.3, but the interface between the web server and mod_jk is version specific and we do use features in 2.x that didn't exist in 1.3. Regards, Rainer
Re: Dynamic configuration for the hackathon?
On 3/27/08 9:00 AM, Nick Kew [EMAIL PROTECTED] wrote: /Lua Fine for users who want to hack their own server. Like Perl. Every play with lighttpd? It's almost the same way... Of course typical lighthttpd user is a hacker. But r.filename is the kind of innards we really don't want to expose to the typical mod_rewrite user! We already expose a lot. You can, indirectly set r-filename with mod_rewrite currently. And if the more complicated modules had a little lua glue: if string.match(r.uri, '/something') then mod_cache:cacheable( r ) end A fine recipe for users shooting themselves in the foot, PHP-style. How would you propose to make that work without hackage to existing modules? I don't. Hence the glue. If one were so inclined, the entire configuration could be lua. Just define and register these functions that need to run per request. That'll go alongside DrBacchus's You can do everything with mod_rewrite :-) If you had lua (or whatever) in configs, you don't need mod_rewrite, alias, etc... Anyway, back to your suggestion of If's and per request configs, I'm +1, especially if it's easily extensible and doesn't parse the tree on every single request. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
updating workers' lbfactor
-- sorry in the case of duplicate messages -- Hi, I notice that in mod_proxy_balancer the workers' lbfactors is dynamically updated without any critical section lock between the call. That is, simply: wsel-s-lbfactor = ival; Quick question: If I am planning to change the lbfactors in my own apache module, is there any critical issue? I think the balancer-manager could cause some problems. Should I put locks in those sections (when updating the lbfactors)? Thanks. -- Vinicius
Re: updating workers' lbfactor
On 03/27/2008 06:20 PM, Vinicius Petrucci wrote: -- sorry in the case of duplicate messages -- Hi, I notice that in mod_proxy_balancer the workers' lbfactors is dynamically updated without any critical section lock between the call. That is, simply: wsel-s-lbfactor = ival; IMHO this should be an atomic operation. So no need for locks. Regards Rüdiger
