mod_wsgi source code preview and feedback
The mod_wsgi module for Apache that I have been talking about for a while now is now at a point where am happy for people to start experimenting with it. If you don't know what I am talking about, this is a module in the same style as mod_python, which implements the Python WSGI specification within Apache. It is completely written in C code, works on all major versions of Apache and runs somewhat better than mod_python for WSGI applications. This is prerelease code though as still have some things to cleanup and chunked transfer encoding support for request content still needs to be implemented. I have started on the documentation but more still to go. Since the audience here has some experience with running mod_python under Apache I reckon you will not have any problems understanding mod_wsgi. I have actually decided to mention availability here even before the Python Web-SIG as some of the WSGI folks over there tend to be somewhat averse to Apache and like to do everything in pure Python. No problem with that here though. :-) If interested, ignore the mod_wsgi stuff on my own site as haven't updated that so as to still give the impression that nothing is ready, instead go to: http://www.modwsgi.org This should send you over to Google code site. There is no tar ball, so you will need to check code out from subversion. There is also currently no build scripts for Windows, but hopefully someone will step up to help me with that task. For basic introduction, the README in the source code is the place to start for now. The site does however have some guides on setting up mod_wsgi with a number of major Python web frameworks and applications. The configuration directives are also documented on the site. Linked off the site you will find a Google group for discussing mod_wsgi, so if you have any questions, want to give me feedback or find bugs use that group rather than this mailing list. Enjoy. Graham
pconf, plog and module logging
Sorry second post, I think I used the wrong sender address the first time. == Hello httpd developers, we ran into a crash on the iSeries platform with mod_jk. It turned out, that the crash was fixed by using the pool plog instead of pconf when allocating logging objects in the post-config hook. Now I want to make sure, that I don't get any negative side effects from switching to plog. Originally I read mod_rewrite.c, because the explanation of plog and pconf didn't give me a rich picture about the life cycle of those pools. mod_rewrite uses pconf when calling - ap_server_root_relative() - ap_open_piped_log() - apr_file_open() inside open_rewritelog(). Other modules like mod_log_config or mod_log_forensic use plog. So what's the general recommendation, which pool to use for the calls above related to log files? Apart from the calls - ap_server_root_relative() - ap_open_piped_log() - apr_file_open() we also allocate two memory structures from the pool (using apr_palloc()), where we keep additional info concerning the loggers. Furthermore: until now we call apr_file_inherit_set(). None of the modules seems to do that. It's implementation in apr is a little tricky, but it seems to register a cleanup handler, that closes the file. Are there general recommendations, if one should call apr_file_inherit_set() for opened log files (or log pipes), and depending on the type of pool used (plog, pconf), which kind of cleanup handler we should register. I ask, because most of the modules seem not to include cleanup handlers for the logging. Any hints are highly welcome! Thanks a lot, Rainer
sed and offline
I'll be offline most of tomorrow and pretty much the whole weekend. Unless I hear vetos, I'll commit the latest mod_sed_filter.c to trunk. If we change the name, which is fine with me, well... that's the joy of svn move :)
Arranging mod_proxy_ajp
Hi,
I have noted that AJP proxy behaves strangely when the connection to the
browser is closed when processing the response. For example:
+++
Wed Mar 14 13:46:05 2007] [error] [client 204.136.114.10] proxy: error
processing body, referer: http://xxx.yyy.zzz/site/cart/index.html
[Wed Mar 14 13:46:05 2007] [error] proxy: got bad response (5) from
(null) (app4)
[Wed Mar 14 13:46:05 2007] [error] proxy: BALANCER:
(balancer://appservers). All workers are in error state for route
(app4-engine3)
+++
Find attached the patch I would like to commit in trunk.
Any comments?
Cheers
Jean-Frederic
Index: modules/proxy/mod_proxy_ajp.c
===
--- modules/proxy/mod_proxy_ajp.c (revision 518577)
+++ modules/proxy/mod_proxy_ajp.c (working copy)
@@ -283,6 +283,7 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, status,
r-server,
ap_get_brigade failed);
+isok = 0;
break;
}
bufsiz = maxsize;
@@ -293,6 +294,7 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, status,
r-server,
apr_brigade_flatten failed);
+isok = 0;
break;
}
}
@@ -303,6 +305,7 @@
if (status != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_DEBUG, status, r-server,
ajp_send_data_msg failed);
+isok = 0;
break;
}
conn-worker-s-transferred += bufsiz;
@@ -370,7 +373,7 @@
if (ap_pass_brigade(r-output_filters,
output_brigade) != APR_SUCCESS) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
- proxy: error processing body);
+ proxy: error processing end);
isok = 0;
}
/* XXX: what about flush here? See mod_jk */
@@ -418,11 +421,11 @@
*/
apr_brigade_cleanup(output_brigade);
-if (status != APR_SUCCESS) {
+if (! isok) {
/* We had a failure: Close connection to backend */
conn-close++;
ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
- proxy: send body failed to %pI (%s),
+ proxy: dialog to %pI (%s) failed,
conn-worker-cp-addr,
conn-worker-hostname);
/*
Re: Arranging mod_proxy_ajp
Jean-Frederic wrote:
-if (status != APR_SUCCESS) {
+if (! isok) {
/* We had a failure: Close connection to backend */
conn-close++;
This is what concerns me (not your code but the old conn-close++.
Hope It wasn't me ;)
Anyhow, AJP should keep the connection to backend open except
when the notification the client has closed the connection is
desired and configured.
I suppose this is one of the reasons why people are saying that
ajp is not much faster then http in mod_proxy.
In any case, +1 for the patch.
Regards,
Mladen.
Re: Arranging mod_proxy_ajp
Mladen Turk wrote:
Jean-Frederic wrote:
-if (status != APR_SUCCESS) {
+if (! isok) {
/* We had a failure: Close connection to backend */
conn-close++;
This is what concerns me (not your code but the old conn-close++.
Hope It wasn't me ;)
Caution: this line exactly has been added as a patch for BZ 40310. I
didn't follow this too closely, but it looked like a serious issue for
the user.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40310
The user comments, that the fix might be relevant for mod_jk too, which
is why I have it on my open items list. But i didn't investigate until now.
Anyhow, AJP should keep the connection to backend open except
when the notification the client has closed the connection is
desired and configured.
I suppose this is one of the reasons why people are saying that
ajp is not much faster then http in mod_proxy.
In any case, +1 for the patch.
Regards,
Mladen.
Re: Arranging mod_proxy_ajp
Rainer Jung wrote: Caution: this line exactly has been added as a patch for BZ 40310. I didn't follow this too closely, but it looked like a serious issue for the user. http://issues.apache.org/bugzilla/show_bug.cgi?id=40310 The user comments, that the fix might be relevant for mod_jk too, which is why I have it on my open items list. But i didn't investigate until now. Right, but then it's a violation of the protocol and the Tomcat fault. If anything except GET_BODY_CHUNK comes in after the header Tomcat should reply with error, and the SEND_HEADER should be repeated. Regards, Mladen.
Re: Arranging mod_proxy_ajp
On Thu, 2007-03-15 at 17:30 +0100, Rainer Jung wrote:
Mladen Turk wrote:
Jean-Frederic wrote:
-if (status != APR_SUCCESS) {
+if (! isok) {
/* We had a failure: Close connection to backend */
conn-close++;
This is what concerns me (not your code but the old conn-close++.
Hope It wasn't me ;)
Caution: this line exactly has been added as a patch for BZ 40310. I
didn't follow this too closely, but it looked like a serious issue for
the user.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40310
isok is set to zero when status != APR_SUCESS in 3 new locations so the
conn-close++ should be called as before the patch.
Cheers
Jean-Frederic
The user comments, that the fix might be relevant for mod_jk too, which
is why I have it on my open items list. But i didn't investigate until now.
Anyhow, AJP should keep the connection to backend open except
when the notification the client has closed the connection is
desired and configured.
I suppose this is one of the reasons why people are saying that
ajp is not much faster then http in mod_proxy.
In any case, +1 for the patch.
Regards,
Mladen.
Re: sed and offline
Jim Jagielski wrote: I'll be offline most of tomorrow and pretty much the whole weekend. Unless I hear vetos, I'll commit the latest mod_sed_filter.c to trunk. If we change the name, which is fine with me, well... that's the joy of svn move :) I was going to throw in one last beg/ for mod_rewrite_body or anything but 'sed' - unless I hear folks are willing to host the basic sed instruction subset (+/- modern GNU language extensions) but svn mv is a good point :) Commit away.
The right way to report problems (was: uninitialized variable in ap_directory_walk)
Hi, almost a week ago I have reported an uninitialized variable in server/request.c. I have also filed a bug (http://issues.apache.org/bugzilla/show_bug.cgi?id=41829). The bug is simple, the patch is simple. Why haven't I got a single reply to my mail? The bug is also still marked as new. What is the right way to report problems? But maybe I should explain the problem a bit. With mod_perl you can add configuration statements by $r-add_config(...). This can also be done in a maptostorage handler which comes handy because it allows you to set some initial values for AllowOverride or Options which are evaluated by the core maptostorage handler. So, with httpd 2.0.x this has worked without problem. With 2.2 the new override_opts were introduced. ap_directory_walk maintains its own copy of these flags along with the current override options in a structure named opts. The members of this structure are initialized from the requests per_dir_config. But somehow the new override_opts had been forgotten. By cause the override_opts member was in my installation always 0 thus preventing to set any other Options via .htaccess. Torsten On Sunday 11 March 2007 18:01, Torsten Foertsch wrote: this bug is alive since 2.2.0. The patch is against trunk. --- server/request.c~ 2007-03-11 17:20:25.0 +0100 +++ server/request.c2007-03-11 17:50:01.0 +0100 @@ -631,6 +631,7 @@ opts.add = this_dir-opts_add; opts.remove = this_dir-opts_remove; opts.override = this_dir-override; +opts.override_opts = this_dir-override_opts; /* Set aside path_info to merge back onto path_info later. * If r-filename is a directory, we must remerge the path_info, pgpggRohOAy25.pgp Description: PGP signature
Re: The right way to report problems (was: uninitialized variable in ap_directory_walk)
On 3/15/07, Torsten Foertsch [EMAIL PROTECTED] wrote: The bug is simple, the patch is simple. Why haven't I got a single reply to my mail? The bug is also still marked as new. What is the right way to report problems? You're doing fine. See: http://httpd.apache.org/dev/patches.html#ignored Joshua.
