Re: Getting ready for 3.2 beta 2
On 01/09/2005, at 6:19 AM, Jim Gallacher wrote:Hey Gang,I think we are ready for the 3.2.1b release. If there are no objections in the next 24 hours I'll create the package and make the announcement on python-dev.Sounds good.I'll always be hoping to sneak in just one more change (eg. MODPYTHON-73),but realities are that I have to stop at some point. :-)BTW, I will be traveling for a few weeks from this weekend and at timeswill be disconnected from the Internet and at other times will only havebasic dial-up access, so you might not hear from me too much duringthat period.Maybe I'll use the time to dream about writing a book. ;-)Graham
Re: Memory leak not fixed from 2003
What's the goal of the question ? The problem is present, and the solution is trivial. Do we have to provide a business case with each bug description ? In this case, the solution implementation would be based on the current use of the software, only in some environments (the ones the people described, so mainly developers). The real question is : Is there any reason to not implement it ? - Original Message - From: Sander Temme [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Monday, August 15, 2005 5:28 PM Subject: Re: Memory leak not fixed from 2003 On Aug 12, 2005, at 2:07 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Bug #25659 is about a memory leak. The (quite trivial) patch has been provided in 2003, and the bug is still not corrected !!! Could somebody include this is next version ? +1 on the patch. This leak is triggered once, in the SSL passphrase handler... do you run into this leak in deployment? Like, do you restart your server a lot? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: svn commit: r264788 - /httpd/httpd/trunk/modules/generators/mod_cgid.c
On Tue, Aug 30, 2005 at 07:58:01PM -0700, Paul Querna wrote: [EMAIL PROTECTED] wrote: Author: colm Date: Tue Aug 30 07:28:48 2005 New Revision: 264788 URL: http://svn.apache.org/viewcvs?rev=264788view=rev Log: If uid_t and gid_t are unsigned on a platform (hurd, for example), using -1 may cause a compiler warning. Why are we re-inventing APR in mod_cgid? That structure comes from unixd.c|h, and changing it would be a massive API/ABI change breaking any third-party modules which implement the get_identity hook. So I left it alone :) mod_cgid seriously needs a major cleaning to use all of the APR functions. cgid is unix-only, is there much point? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r264737 - /httpd/httpd/trunk/docs/manual/stopping.xml
On Tue, Aug 30, 2005 at 10:37:07PM +0100, Colm MacCarthaigh wrote: On Tue, Aug 30, 2005 at 06:00:47PM +0100, Colm MacCarthaigh wrote: On Tue, Aug 30, 2005 at 05:25:07PM +0100, Joe Orton wrote: So is mod_cgid still the default CGI module for worker because there once existed some ye-olde-Unixes which had an interesting fork() implementation? Given that POSIX has mandated since 2001 or whatever that fork() duplicates only the calling thread, is there any disadvantage to using mod_cgi in all MPMs on modern platforms? Can't think of any, and performance is easy to measure. Just some comparitive ab's, all with Linux 2.6.13, NPTL, ab -n 5000 -c 10 http://localhost/cgi-bin/test-cgi MPM cgidcgi worker 594.28 588.69 req/sec. event 665.11 661.28 req/sec. leader 598.14 592.86 req/sec. threadpool 594.94 591.87 req/sec. There seems to be a very consistent .1% advantage to using mod_cgid, for me at least. Of course, cgid eats a process table entry and some memory, but fork()'ing a plain process does seem to be less overhead. Apologies for the previous empty mail ;) If the performance difference is that small then mod_cgi is definitely a better default IMO: it has much better stderr handling (the CGI bucket stuff) and it will log to the correct vhost-specific logs. joe
Re: svn commit: r264737 - /httpd/httpd/trunk/docs/manual/stopping.xml
On Wed, Aug 31, 2005 at 10:24:49AM +0100, Joe Orton wrote: Apologies for the previous empty mail ;) If the performance difference is that small then mod_cgi is definitely a better default IMO: it has much better stderr handling (the CGI bucket stuff) and it will log to the correct vhost-specific logs. +1 on changing the default, cgid can remain available for .1% freaks. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r264737 - /httpd/httpd/trunk/docs/manual/stopping.xml
On 8/31/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Aug 31, 2005 at 10:24:49AM +0100, Joe Orton wrote: Apologies for the previous empty mail ;) If the performance difference is that small then mod_cgi is definitely a better default IMO: it has much better stderr handling (the CGI bucket stuff) and it will log to the correct vhost-specific logs. +1 on changing the default, cgid can remain available for .1% freaks. I keep a quote from Ulrich Drepper on the wall behind my monitor (somewhere between the TCP state transition diagram and how to write a DVD on Linux): No threaded program must use anything but _exit or exec after fork. apr_proc_create() does a lot more than that. It isn't that I believe the statement to be the absolute truth given infinite programming time and highly constrained web server APIs (neither of which we have), but I believe it is wise to follow anyway. Sadly, mod_ext_filter calls apr_proc_create() similar to mod_cgi and is subject to race conditions in threaded servers under heavy load, with pipe handles open in the wrong processes which prevent the children from seeing EOF on their stdin (due to magic of fork, handles intended for a particular child get duped in another child). A lock to be held by any code dorking with file descriptors or forking is needed to prevent file descriptors from being duplicated unexpectedly in children. What about mutexes? Does the forked, held mutex get released automatically by the new child when it does exec()? Does it depend on which type of mutex? Is APR going to have to use atfork handlers to clean up its own mutexes to prepare for this scenario? (which wouldn't help the typical commercial third-party module which has its own portability layer to support deployment in Apache, IIS, SunOne, etc.) (I keep the idea of a fork service in the back of my mind, which generalizes the daemon feature of mod_cgid for use by any Apache modules which need to create child processes from MPM threads.)
2.1.7/2.2 status
Hi, I was 10 days on vacation, and seems I've lost the thread :) Can someone state what is the 2.1.x policy: CTR or RTC? Regarding 2.1.7, I said that windoze implementation core dumps (proxy load balancer), so for me the 2.1.7 is broken, although as I read, mine -1 vote is useless. Anyone tried 2.1.7 on WINxx? Anyhow, what is the purpose of the vote if the -1 irrelevant? Regards, Mladen.
Re: svn commit: r264737 - /httpd/httpd/trunk/docs/manual/stopping.xml
On Wed, Aug 31, 2005 at 06:54:03AM -0400, Jeff Trawick wrote: On 8/31/05, Colm MacCarthaigh [EMAIL PROTECTED] wrote: On Wed, Aug 31, 2005 at 10:24:49AM +0100, Joe Orton wrote: Apologies for the previous empty mail ;) If the performance difference is that small then mod_cgi is definitely a better default IMO: it has much better stderr handling (the CGI bucket stuff) and it will log to the correct vhost-specific logs. +1 on changing the default, cgid can remain available for .1% freaks. I keep a quote from Ulrich Drepper on the wall behind my monitor (somewhere between the TCP state transition diagram and how to write a DVD on Linux): No threaded program must use anything but _exit or exec after fork. apr_proc_create() does a lot more than that. It isn't that I believe the statement to be the absolute truth given infinite programming time and highly constrained web server APIs (neither of which we have), but I believe it is wise to follow anyway. must not use anything but async-signal-safe functions is actually what the standard requires FWIW. Sadly, mod_ext_filter calls apr_proc_create() similar to mod_cgi and is subject to race conditions in threaded servers under heavy load, with pipe handles open in the wrong processes which prevent the children from seeing EOF on their stdin (due to magic of fork, handles intended for a particular child get duped in another child). A lock to be held by any code dorking with file descriptors or forking is needed to prevent file descriptors from being duplicated unexpectedly in children. Ah, I always forget about this people using threaded servers are doomed scenario. I guess all the people voting to make worker the default MPM do too... Regardless of cgid vs cgi, how much of this is it feasible to fix? APR has to require that all child_cleanup functions are async-signal-safe; that's probably doable. Can apr_proc_create just do some close all fds 3 in the forked child? I guess it all gets too icky. joe
Re: Status of 2.1.7
It kind of nice the amount of activity in the 2.1 tree, and I'd be somewhat hesitant to restrict that; people like working on code that will actually be released and used within the year :) Before we release 2.2, I think we should have a real plan on what 2.4 (or 3.0) will look like. Otherwise, we will have 3 code bases in RTC, and no real place to direct energy and vitality to. Unless, of course, we go back to the concept of releasing early and often. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Sith happens - Yoda
Re: Status of 2.1.7g
Justin Erenkrantz wrote: --On August 30, 2005 8:54:57 AM -0400 Jeff Trawick [EMAIL PROTECTED] wrote: http://people.apache.org/~colm/2.1.7-non-showstoppers.patch +1 on all that for the 2.2.x branch in any case. +1 here as well +1 too on that set of changes. I think we hit RTC once the branch opens towards GA - which'll happen once we issue a release from it. -- justin +1 from me as well. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Sith happens - Yoda
ProxyPass ajp://localhost:8009 max=10 useless?
I have been struggling for two weeks trying to integrate Apache2.1.6-alpah and TOMCAT 5.5.9. I am very appreciated that someone could help me here. Below is the configuration that I used: IfModule mod_proxy.c ProxyPass /jspdir ajp://localhost:8009/jspdir ProxyPassReverse /jspdir ajp://localhost:8009/jspdir /IfModule When I tested with lots of connections, soon I found there are some errors in Apache log and Tomcat log. In Apache log: [Wed Aug 31 16:29:07 2005] [notice] Apache/2.1.7 (Unix) mod_ssl/2.1.7 OpenSSL/0.9.8 configured -- resuming normal operations [Wed Aug 31 16:32:22 2005] [error] ajp_check_msg_header() got bad signature 426 [Wed Aug 31 16:32:22 2005] [error] ajp_ilink_receive() received bad header [Wed Aug 31 16:32:22 2005] [error] ajp_read_header: ajp_ilink_receive failed [Wed Aug 31 16:32:22 2005] [error] (120007)APR does not understand this error code: proxy: read response failed from (null) (*) [Wed Aug 31 16:32:22 2005] [error] ajp_check_msg_header() got bad signature d3a [Wed Aug 31 16:32:22 2005] [error] ajp_ilink_receive() received bad header [Wed Aug 31 16:32:22 2005] [error] ajp_read_header: ajp_ilink_receive failed [Wed Aug 31 16:32:22 2005] [error] (120007)APR does not understand this error code: proxy: read response failed from (null) (*) In TOMCAT log: Aug 31, 2005 11:08:56 AM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (8,000) are currently busy, waiting. Increase maxThreads (8,000) or check the servlet status So to limit the number of connections to TOMCAT, I set the max parameter behind ProxyPass ProxyPass /jspdir ajp://localhost:8009/jspdir max=10 I run test again, and errors occured again. I used netstat -an to see how many connections to localhost:8009. And I found the number of connections are greater than 10!!! So is the max parameter useless for proxy_ajp connection? Any suggestions of configuration? Thx, Xuekun
Re: mod_smtpd module review
On Aug 30, 2005, at 11:19 AM, Brian J. France wrote:
This past week I have finished up a few modules and ready for review.
http://www.brianfrance.com/software/apache/mod_smtpd_load.tar.gz
mod_smtpd_load:
This module allows rejecting connection (temporarily) based on
server load
It is not very cross platform (any os with getloadavg), but I am
sure we
can work on that.
I have finished mod_smtpd_access_dbi, but after talking with Paul
on IRC
I need to convert it to use mod_dbd instead of mod_dbi_pool.
Working on that
now and will post another message when done. I could build a tar
ball of this
module if anybody is interested as the the flow will not change,
just how the
db connection is handled.
mod_smtpd_access_dbi:
This module is similar to sendmails access file. It allows
checking of the ip/hostname/from/to items via a database to see if
things should be rejected. It uses mod_dbi_pool and libdbi.
Thanks to Paul for mod_dbi_pool and code examples from
mod_vhost_dbi.
This is great!
A few things I have found while writing these modules. How about
changing smtpd_return_data from this:
typedef struct smtpd_return_data {
apr_pool_t *p;
/* list of messages */
apr_array_header_t *msgs;
} smtpd_return_data;
to something like this:
typedef struct smtpd_return_data {
apr_pool_t *p;
int code;
/* list of messages */
apr_array_header_t *user_msgs;
apr_array_header_t *log_msgs;
} smtpd_return_data;
While doing the mod_smtpd_load module I found when I want to deny a
connection I can set what message the user will get, but I also
want to log a different message instead of the default Connection
Denied (current I log my own and the default gets logged). Of
course this might be another thread of how and what do we plan on
logging.
IMO I think that logging twice is fine. mod_smtpd logs Connection
Denied because a server admin may want to know what connections are
getting denied for debugging and etc. and I feel its absolutely
necessary, same with the MAIL command. If your module wants to log
extra information, I think that's OK.
Maybe for clarity all mod_smtpd's logs can be prefixed with
mod_smtpd: and other modules can follow suit.
I would also like to set the error code, because looking over
rfc0821 I think it should return 452 or may be that needs to be a
default for smtpd_run_connect soft errors (552 for hard errors).
Should we allow the module to set the error code?
Error codes can be sent with SMTPD_DONE. Otherwise error codes won't
change in the next fifty years for things like SMTPD_DENY and
friends. I'll look into changing those specific codes. Most of the
error codes I got from Postfix and Qpsmtpd but of course they aren't
perfect.
In mod_smtpd_access_dbi I found it strange that I get a string that
looks like this: [EMAIL PROTECTED] instead of
[EMAIL PROTECTED]. For the mail/rcpt hooks should we send a struct
that has the full line sent, the data from the full line and the
parsed email address? I have some code that duplicates the string
and then remove spaces and from the beginning and from the end,
but that seems like it should be done before my function is
called. Another problem I can see is when we get into things like
the size options:
MAIL FROM:[EMAIL PROTECTED] SIZE=50
Do we want every module to have to parse the email address
(removing ) and the SIZE?
This is a very good point. Honestly I'm not really sure since I'm not
experienced with writing a plugin based architecture, but I'm almost
positive that most people will say that mod_smtpd should parse the
email address and options along with it. When I first wrote mod_smtpd
I figured I'd pass the un-parsed string after from: verbatim to let
the modules decide what to do with it. Maybe to allow some crazy
things. Either way, having mod_smtpd parse sounds like the right idea
so how about this hook for mail:
smtp_run_mail(smtp_conn_rec *, smtp_return_data *, char
*parsed_address, apr_array_header_t *options);
The options won't be stored as name-value pairs: more like an array
of strings like SIZE=5. Does that sound good?
Rian Hunter
Re: svn commit: r265523 - in /httpd/httpd/trunk/server/mpm: experimental/event/event.c experimental/leader/leader.c experimental/threadpool/threadpool.c prefork/prefork.c
On 8/31/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: colm Date: Wed Aug 31 09:10:55 2005 New Revision: 265523 URL: http://svn.apache.org/viewcvs?rev=265523view=rev Log: Initiliase all of the first_*_limit variables to zero, so that we can actually raise limits beyond their defaults reliably. How can a C-language global variable not be initialized to zero?
A mod_mbox release ?
Hi list, As most of you probably already know, we hit the Summer of Code deadline. I've been committing a lot of mod_mbox stuff recently in order to get the work done for today, and I'm pleased to say that mod_mbox is now operational. My development branch (httpd-mbox-if) has been heavily tested since I started working on the project, thus allowing several bugs to be located and fixed. I'm now wondering about the near future of my branch, and what we should do about it. I'd like to drop a milestone. How do we usually proceed : - just tag my branch as tags/soc/ ? - merge the changes into trunk/ ? - release mod_mbox 0.2 ? I have no idea, and the new committers guide does not say much about it. What about mail-archives.apache.org ? I think my work needs some kind of profound review (segfaults ? security holes ?) before being using in production. However, I'll be very proud to see m-a.a.org switching to the new code. Please note that a source tarball and a working binary debian package are already built, but I guess there must be some kind of review for these things, too. Regards, - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: svn commit: r265523 - in /httpd/httpd/trunk/server/mpm: experimental/event/event.c experimental/leader/leader.c experimental/threadpool/threadpool.c prefork/prefork.c
On Wed, Aug 31, 2005 at 01:02:55PM -0400, Jeff Trawick wrote: Initiliase all of the first_*_limit variables to zero, so that we can actually raise limits beyond their defaults reliably. How can a C-language global variable not be initialized to zero? A gcc ia64 bug, possibly. I can't raise ThreadLimit without those changes. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r265523 - in /httpd/httpd/trunk/server/mpm: experimental/event/event.c experimental/leader/leader.c experimental/threadpool/threadpool.c prefork/prefork.c
On Wed, Aug 31, 2005 at 06:11:21PM +0100, Colm MacCarthaigh wrote: On Wed, Aug 31, 2005 at 01:02:55PM -0400, Jeff Trawick wrote: Initiliase all of the first_*_limit variables to zero, so that we can actually raise limits beyond their defaults reliably. How can a C-language global variable not be initialized to zero? A gcc ia64 bug, possibly. I can't raise ThreadLimit without those changes. Yep, it's a compiler bug, meddling with optimisations fixes it too. I don't see any harm in leaving the assignment in though. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: A mod_mbox release ?
Hi, As most of you probably already know, we hit the Summer of Code deadline. I've been committing a lot of mod_mbox stuff recently in order to get the work done for today, and I'm pleased to say that mod_mbox is now operational. Well, it was operational before. ;-) Sorry, I meant to say the new mod_mbox code is operational. I would call for a review of your changes pending a merge into trunk. At that point, I (and others) need to sit down and review all of your changes in detail. I will admit that I haven't been able to keep as close an eye on your commits as I would have preferred. (Perhaps others have?) Yes, I think my code really needs a full review, and I'll be pleased to have as many comments as possible in order to improve my work. Agreed. The goal will be to place it in production; however, at the least, we need to block (or warn) known-buggy browsers from accessing the AJAX interface. This is already done (see r264664). Per our policies, any release requires 3 +1s before going public - so you need to get three folks to sign off on it first. As I'm sure OtherBill will rush to point out, you aren't technically on the PMC yet, so you need to find three folks who are on the PMC to cast their vote for release. Once you get on the PMC, you can then vote for a release. When Roy returns from vacation, he's promised to clean up our committer and PMC membership rosters... Ok, I'll call for a vote when the code has been reviewed, fixed, etc. Thanks, - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: ProxyPass ajp://localhost:8009 max=10 useless?
Xuekun Hu wrote: [..cut..] So to limit the number of connections to TOMCAT, I set the max parameter behind ProxyPass ProxyPass /jspdir ajp://localhost:8009/jspdir max=10 I run test again, and errors occured again. I used netstat -an to see how many connections to localhost:8009. And I found the number of connections are greater than 10!!! So is the max parameter useless for proxy_ajp connection? Any suggestions of configuration? Apart from the fact that I think that these questions belong to the users list: max ensures that not more then max connections get created *per* Apache child process. So the questions are 1. What MPM do you use? 2. What is your setting for ServerLimit? Provided that you use the worker MPM the maximum number of total connections httpd creates is max * ServerLimit. Regards Rüdiger
Re: ProxyPass ajp://localhost:8009 max=10 useless?
Thanks for your answer. Now I understand what the max means. However the errors occured again. I don't know if the error shows a bug or just my configuration error, so I sent to dev list. I used worker MPM. ThreadLimit 600 IfModule worker.c StartServers 4 MaxClients 24000 ServerLimit 50 MinSpareThreads 1000 MaxSpareThreads 2000 ThreadsPerChild 600 MaxRequestsPerChild 0 ListenBackLog 3000 /IfModule MaxRequestsPerChild 0 ProxyPass /jspdir ajp://localhost:8009/jspdir max=10 My TOMCAT configuration: Connector port=8009 maxHttpHeaderSize=8192 maxThreads=8000 minSpareThreads=4000 maxSpareThreads=8000 acceptCound=5 enableLookups=false redirectPort=8443 protocol=AJP/1.3 tomcatAuthentication = false / So the max connections httpd created should be 50 * 10 = 500, however TOMCAT threads are 8000. So why these errors happened? (Apache errors happened first, then TOMCAT errors). Thx, Xuekun Apart from the fact that I think that these questions belong to the users list: max ensures that not more then max connections get created *per* Apache child process. So the questions are 1. What MPM do you use? 2. What is your setting for ServerLimit? Provided that you use the worker MPM the maximum number of total connections httpd creates is max * ServerLimit. Regards Rüdiger
