Re: new mod_python faq (fwd)
I'll deal with it.
Jim
Gregory (Grisha) Trubetskoy wrote:
This was sent to me directly, anyone willing to act on it? (I don't have
the CPU cycles right now).
-- Forwarded message --
Date: Mon, 17 Jul 2006 18:12:07 +0200
To: [EMAIL PROTECTED]
Subject: new mod_python faq
I think may be useful to add this question:
2.30. Why do I get No space left on device: Failed to create global
mutex ?
Because mod_python has get all the available semaphores of your os.
To avoid this error on GNU/Linux do
#ipcs (to see all locked semaphores)
#for i in `ipcs | grep www-data | awk '{print $2}'`; do ipcrm -s $i;
done
www-data is the user which runs apache[12] (in Debian)
In this way you release all resources locked by apache[12]
If you want to increase the number of available semaphores append
kernel.sem = 512 32000 100 512
to your /etc/sysctl.conf
and do
#sysctl -p
--
Some of the content has benne derived from
http://www.modpython.org/pipermail/mod_python/2005-April/017858.html
You can change anything you want of course :)
Thank you for the great work
(even if configuring mod_python in debian is painfully... )
Re: release 3.2.10?
I'm +1 on going for 3.2.10. You in Canada probably have it easier - I think we hit 96F/35C at some point today or yesterday (I wouldn't know I'm in the office which has AC sunrise to sunset, I just listen to the news), and unfortunately (or not) due to work pressures I have no time for anything - no frolicking for me this summer :-( Grisha On Sun, 16 Jul 2006, Jim Gallacher wrote: Graham Dumpleton wrote: Jim Gallacher wrote .. Shall we proceed with a 3.2.10 release with the current memory leak fixes, or keep digging for more leaks? Seeing as it's summer for most of us (except for Graham), I get the feeling people don't have a lot of free time to spend on mod_python right now. Just because it is winter down here and I'm freezing my butt off doesn't mean I am any less busy. :-( Oh, I wasn't suggesting you were any less busy - just that folks in the northern hemisphere may well choose to frolic in the summer sun rather that hack away at mod_python in their spare time. :) Jim
Re: release 3.2.10?
On Tue, 18 Jul 2006, Jim Gallacher wrote: For 3.2.9 I called for 2 rounds of testing: one for the release candidate and one for the final tarball. Do folks here feel that is necessary for 3.2.10 or should I just jump right to the 3.2.10 final? That tarball would still be subject to a vote on this list before an official release. Cutting out the first step will save a few days. I think what you term it doesn't matter - if it's voted down, it will be voted down, be it 3.2.10 RC or 3.2.10 Final (we'll just have to make a 3.2.11 then). So just go for it :-) Grisha
Re: release 3.2.10?
Gregory (Grisha) Trubetskoy wrote: (we'll just have to make a 3.2.11 then). Let's call that one the Spinal Tap version. :)
Re: [Patch]: Do not compress bodies of header only requests in mod_deflate
That makes sence and explains why i couldn't use a HEAD request to ge the content-lenght of a list of file while mod_deflate was on.On 7/18/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:Jorge Schrauwen wrote: I might be getting this all wrong but doesn't the Content-Lenght require mod_deflate to run? for the correct lenght to be set?If we won't send content-length, but instead send content-encoding chunked, then there's no reason to compute content length, no reason to refilter theresponse.Bill-- ~Jorge
Re: [Patch]: Do not compress bodies of header only requests in mod_deflate
On 07/18/2006 01:05 AM, Henrik Nordstrom wrote: It's not in case of C-L. For a starter HEAD is used by quite many robots with simplistic caches to verify that the copy they have is current and correct. The RFC is quite strict that entity headers of a HEAD response SHOULD match those of a identical GET request, so difference in C-L is not acceptable by the RFC. (T-E is transport, and may differ) I feared that. So I will leave everything as it is. It's a pity T-E gzip isn't deployable. Would eleminate this whole question as it's not an entity transform.. Yes, that is a real pity. Regards Rüdiger
mod_proxy feature coming up
Pretty soon I'll be committing my balancer set patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the set element. I will also at this time likely add a busy element as well, in anticipation of the by-busyness LB method patch ;)
Re: mod_proxy feature coming up
Jim Jagielski wrote: Pretty soon I'll be committing my balancer set patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. Huh, thanks :) I've only spend two weeks on it. -- Mladen.
Re: mod_proxy feature coming up
Jim Jagielski wrote: Pretty soon I'll be committing my balancer set patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the set element. I will also at this time likely add a busy element as well, in anticipation of the by-busyness LB method patch ;) Nice I have also prepared memory slot handler to replace the scoreboard space used by mod_proxy may I should wait before committing the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? Cheers Jean-Frederic
Re: mod_proxy feature coming up
Jean-frederic Clere wrote: Jim Jagielski wrote: Pretty soon I'll be committing my balancer set patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the set element. I will also at this time likely add a busy element as well, in anticipation of the by-busyness LB method patch ;) Nice I have also prepared memory slot handler to replace the scoreboard space used by mod_proxy may I should wait before committing the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
[Fwd: Re: Invalidation after updates or deletions]
Cache validation is not my expertise although I've enjoyed participating in the banter over how to support 1 to 3 hit cache lookups of variants which also vary ;-) This thread is certainly of interest to those of you working in the area of cache invalidation, current in discussion and raised by Mark Nottingham on the HTTP-WG discussion list. One thing occurred to me. mod_ftp treats ftp 'commands' as http 'methods'. So RETR is equivilant to a GET. His point about and unrecognised request methods reminds me there is no way for a module to reflect that a method it handled was idempotent or otherwise harmless to the ETag and content of the cache. If your module implements PATCH, as this modifies the resource, there is no harm since it's unrecognized by the cache. If your module implements GET-HTML-HEAD, we have a problem since cache doesn't recognize and your module can't inform. It would be cool to have an idempotence flag in the next major release for handlers/filters to say that the arbitrary method operation munged the origin, or it did not. Thoughts? Bill ---BeginMessage--- On Mon, 17 Jul 2006, Mark Nottingham wrote: RFC2616 says that POST, PUT, DELETE and unrecognised request methods passing through a cache MUST invalidate one or more cache entries (depending on the values of the Location and Content-Location headers). http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10 In my informal (and not yet complete) testing, I've only found one cache implementation -- client or intermediary -- that actually does this. I've tried to engage various vendors, etc. to fix it, but haven't seen much interest. Good, my implementation seems to behave properly (although I didn't check with Location and Content-Location). In 13.10, there is also a paragraph about DoS invalidation attacks using fake Content-Location, and there is a assumption about domain of control of URIs: In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI. As having the same host does not mandate any kind of exclusive control over the content of a web server, should we downgrade this MUST in a SHOULD ? (or even delete it and put warning text about possible DoS attack) -- Yves Lafon - W3C Baroula que barouleras, au tiéu toujou t'entourneras. ---End Message---
Re: [Fwd: Re: Invalidation after updates or deletions]
On 18.07.2006 17:46, William A. Rowe, Jr. wrote: It would be cool to have an idempotence flag in the next major release for handlers/filters to say that the arbitrary method operation munged the origin, or it did not. Thoughts? This can be difficult. How do you want to handle this with proxies? What would be the default for 3rd party modules that do not set it? Regards Rüdiger
Re: [Fwd: Re: Invalidation after updates or deletions]
Ruediger Pluem wrote: On 18.07.2006 17:46, William A. Rowe, Jr. wrote: It would be cool to have an idempotence flag in the next major release for handlers/filters to say that the arbitrary method operation munged the origin, or it did not. Thoughts? This can be difficult. How do you want to handle this with proxies? What would be the default for 3rd party modules that do not set it? As far as the downstream, I'm thinking such a marker would trigger our http filter to add the appropriate cache control directives - if it's possible. If not, the downstream should follow the RFC and render unknown methods as uncachable and cache-invalidating. Not the end of the world. Bill
Re: [Fwd: Re: Invalidation after updates or deletions]
Ruediger Pluem wrote: What would be the default for 3rd party modules that do not set it? Follow the RFC of course, GET, HEAD and OPTIONS are idempotent, other methods are not. Good point - we need a decisive yes/no and unset value here.
Re: mod_proxy feature coming up
On Jul 18, 2006, at 11:29 AM, Jim Jagielski wrote: Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Of course, another option would be creating a quick httpd-trunk branch (httpd-proxy-scoreboard??) and committing the patch there, and we can then merge at some soon future point. We should really use SVN's cheap branches as much as possible...
Re: mod_proxy feature coming up
Jim Jagielski wrote: Jean-frederic Clere wrote: Jim Jagielski wrote: Pretty soon I'll be committing my balancer set patch to httpd-trunk. This basically allows for member sets within a balancer similar to the 'distance' mod_jk attribute. What it does is allow for more control over which members will be used via m_p_b. The logic is: Look for all usable members in set #0 If none exist, look for any host standbys in #0 If none exist, select the next set and loop I think this design provides the most flexibility for the admin. Anyway, this will require an update to the pertinent data struct to add the set element. I will also at this time likely add a busy element as well, in anticipation of the by-busyness LB method patch ;) Nice I have also prepared memory slot handler to replace the scoreboard space used by mod_proxy may I should wait before committing the part that affects mod_proxy.c, proxy_util.c and mod_proxy.h? Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Ok. That gives me time to write more memory slot handler. Cheers Jean-Frederic
Re: mod_proxy feature coming up
Jean-frederic Clere wrote: Ok. That gives me time to write more memory slot handler. Mladen's also let me know offlist that he's working on some AJP stuff as well, so the current schedule is that after he's added that, I'll add my member set patch. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy feature coming up
Jim Jagielski wrote: On Jul 18, 2006, at 11:29 AM, Jim Jagielski wrote: Yes, I'd propose waiting to commit that. The sole reason is that the member-set and other previously committed patches will likely be more readily approved for backporting to 2.2.x, whereas the scoreboard changes might be more difficult :) Of course, another option would be creating a quick httpd-trunk branch (httpd-proxy-scoreboard??) and committing the patch there, and we can then merge at some soon future point. We should really use SVN's cheap branches as much as possible... Ok I will create a branch and we will merge it later. Cheers Jean-Frederic
http://svn.apache.org/repos/asf/httpd/mod_arm4/trunk/
December 2nd 2004 Bill Stoddard committed the start of a mod_arm4 instrumentation module to the httpd project. I believe that was always intended to be a module of [EMAIL PROTECTED], and not a 'subproject'. However, we are coming up on 20 months of code, with no signal of a release. Would it be unreasonable to suggest that a release candidate should come into existance in the next few weeks for review and release? If users can't put their hands on a tarball, they are less than likely to adopt a module. As we like to say, release early and often. Once would be nice :) I raised the issue in another thread quite a while back, and don't remember seeing a response. But I've been in a cobweb-cleaning mood, so forgive if I get in a roll :) Bill
Re: release 3.2.10?
Jim Gallacher wrote: Deron Meranda wrote: Just want some verification because I haven't seen anything official looking Is 3.2.9 now considered a bad release because of its memory leaks, and thus will never be released? It's not so much that it's a bad release, but rather it didn't make sense to officially release 3.2.9 and then turn around and release 3.2.10 a week later. The leak that will be fixed in 3.2.10 is not new in 3.2.9, only newly discovered. Hence 3.2.10 will be the next hopeful stable release after 3.2.8? Basically yes, but if you are already using 3.2.9 there is no harm specific harm. At any rate, I'll roll a 3.2.10 tarball for testing by the list tonight. Best laid plans and all that... For 3.2.9 I called for 2 rounds of testing: one for the release candidate and one for the final tarball. Do folks here feel that is necessary for 3.2.10 or should I just jump right to the 3.2.10 final? That tarball would still be subject to a vote on this list before an official release. Cutting out the first step will save a few days. Jim
Re: [TALLY] Release mod_aspdotnet build 2004?
Summary; +1 binding: wrowe +1 nonbinding feedback (with qualitative data) from: Jorge Schrauwen James Park (pencil_ethics) Trent Nelson As none of the other pmc members care to inspect the source tarball, the vote fails. As Roy has raised concerns about httpd's ongoing ownership, even of the prior release, that too will be removed from the active www.apache.org/dist/httpd/mod_aspdotnet location. archive.apache.org is a lovely permanent museum for that wrinkle in time (2.0.0.2000 21 Nov 2004). As 2.0.4 and the various snapshots between now and then are not releases, those have been removed from /dev/dist. It will take me a few days to find the free cycles to expunge the trunk of httpd/docs/manual/, downloads.cgi, etc and then remove /dist/httpd/mod_aspdotnet. As there is no oversight going on here, no further commits will occur to bring mod_aspdotnet to Visual Studio 2005 here. What does the list want to do with the unreleased mod_arm4 and mod_aspdotnet code repositories? Do we want to create a /repos/asf/httpd/attic/ repository for abandoned/orphaned httpd code? Or simply svn rm them, knowing they still persist at certain points in history and can be resurrected? To those disappointed, I share your disappointment, but have no regret. This is what it is. I have spent considerable time reviewing the history of posts to cli-dev, cli-users, and the bugtraq database. No specific individuals stand out as frequent posters of bug fixes (not that many were needed), peer to peer user feedback authors etc. Obviously one solution would be to draft the few that express an interest here and now, but the httpd project (appropriately) expects a reasonable track record to avoid exactly this sort of issue. Although this was a rather mature module from it's inception, with a very short list of issues that users wanted addressed, it certainly attracts many more users than developers. The net code changes since it was granted two years ago are less than 250 LoC, and developing -within- the framework has much more interest than developing the -module-, itself. I'm afraid this is no different than the passing of JRun and other similar, now abandoned code. Developers and their technologies move on. It would be amusing if the project spent 5% of the effort that's invested in Apache 1.3 to review this release, but that wasn't to be. Sadly yours, Bill William A. Rowe, Jr. wrote: Build 2004 of mod_aspdotnet is prepared (after a number of abortive attempts due to the whole 2.0/2.2 partitioning and renaming of apache.exe, along with switching flavors of InstallShield to a version I have installed) and seeking voters. The update is here; http://httpd.apache.org/dev/dist/mod_aspdotnet/ Please cast your +/- 1's to release mod_aspdotnet-2.x.0.2004-source.zip (along with associated binaries ...2.0.0.2004.msi and ...2.2.0.2004.msi, one corresponding to 2.0.44 and later, the other to 2.2.2 and later). This is the last expected release on the Visual Studio .NET (al la 2002) compiler toolchain; the next effort is porting it to VS 2005 (al la, the one available in a free flavor). Porting breaks compatibility with the older tools, since VS 2005's C++.NET schema is miles beyond 2002. For example, a reference becomes a reference, not an overloaded psuedo-pointer. Bill .
